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.
Right. > 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: http://support.amd.com/TechDocs/50742_15h_Models_60h-6Fh_BKDG.pdf 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 2.16.1.10 [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 2.16.1.6 [Handling Machine Check Exceptions]. 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 least. 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... Thanks. -- Regards/Gruss, Boris. ECO tip #101: Trim your mails when you reply.
