Re: [PATCH] KVM: SVM: fix trashing of MSR_TSC_AUX

From: Borislav Petkov
Date: Fri Jul 08 2016 - 08:56:08 EST

On Fri, Jul 08, 2016 at 07:15:39AM -0400, Paolo Bonzini wrote:
> It does sometimes happen that there is no state. For example it could be
> an MSR that we are already getting in and out of KVM.


> However, it is way more common that you have to add support for
> reading/writing the MSR in KVM as well, and then teach QEMU's
> target-i386/kvm.c about it as well.
> It's hard to say without knowing exactly what the feature is about...
> Is there an architecture manual out there that documents it?

Maybe section 2.16 here:

In any case, here are two bit definitions:

1 SUCCOR: Software uncorrectable error containment and recovery
capability. Value: 1. 1=The processor supports software containment of
uncorrectable errors through context synchronizing data poisoning
and deferred error interrupts; see [Deferred Errors and Data
Poisoning]; MSR MSRC000_0410 [Machine Check Deferred Error Configuration
(CU_DEFER_ERR)] exists.

0 McaOverflowRecov: MCA overflow recovery support. Value: 1. 1=MCA
overflow conditions (MCi_STATUS[Overflow]=1) are not fatal; software
may safely ignore such conditions. 0=MCA overflow conditions require
software to shut down the system. See [Handling Machine Check

So AFAICT the McaOverflowRecov thing should be the easiest by making
sure MCi_STATUS[Overflow]=1 is set properly when MCEs happen.

The SUCCOR thing needs data poisoning and deferred error interrupts and
that's a lot more involved than the overflow handling. And we'll need to
touch a lot more places. But it doesn't hurt to start looking at them at

Bottom line is, the more RAS features we could test with qemu/kvm the
better because generating those error conditions on a real system is
very very hard and sometimes even impossible. Especially if you try to
inject an error but then the BIOS facility which does that is b0rked
because vendor forgot it. Crap like that.

I'll do some looking into all that when I get free moments, who knows,
we might get something going...



ECO tip #101: Trim your mails when you reply.