From: Borislav Petkov <bp@alien8.de>
To: Paolo Bonzini <pbonzini@redhat.com>
Cc: Eduardo Habkost <ehabkost@redhat.com>,
linux-kernel@vger.kernel.org, kvm@vger.kernel.org,
stable@vger.kernel.org, Yazen Ghannam <yazen.ghannam@amd.com>,
Brijesh Singh <brijesh.singh@amd.com>,
Tony Luck <tony.luck@intel.com>
Subject: Re: [PATCH] KVM: SVM: fix trashing of MSR_TSC_AUX
Date: Fri, 8 Jul 2016 14:55:54 +0200 [thread overview]
Message-ID: <20160708125553.GG3808@pd.tnic> (raw)
In-Reply-To: <1475224135.5251432.1467976539798.JavaMail.zimbra@redhat.com>
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.
next prev parent reply other threads:[~2016-07-08 12:56 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-07-06 13:43 [PATCH] KVM: SVM: fix trashing of MSR_TSC_AUX Paolo Bonzini
2016-07-06 14:18 ` Borislav Petkov
2016-07-06 14:29 ` Paolo Bonzini
2016-07-07 10:41 ` Borislav Petkov
2016-07-07 11:01 ` Paolo Bonzini
2016-07-07 11:47 ` Borislav Petkov
2016-07-07 12:28 ` Paolo Bonzini
2016-07-07 12:47 ` Borislav Petkov
2016-07-07 13:16 ` Paolo Bonzini
2016-07-07 16:01 ` Borislav Petkov
2016-07-07 16:17 ` Paolo Bonzini
2016-07-07 16:27 ` Eduardo Habkost
2016-07-07 17:04 ` Borislav Petkov
2016-07-07 17:43 ` Eduardo Habkost
2016-07-08 11:09 ` Borislav Petkov
2016-07-08 11:15 ` Paolo Bonzini
2016-07-08 12:55 ` Borislav Petkov [this message]
2016-07-06 15:00 ` kbuild test robot
2016-07-15 12:15 ` Radim Krčmář
2016-07-15 12:30 ` Paolo Bonzini
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20160708125553.GG3808@pd.tnic \
--to=bp@alien8.de \
--cc=brijesh.singh@amd.com \
--cc=ehabkost@redhat.com \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=pbonzini@redhat.com \
--cc=stable@vger.kernel.org \
--cc=tony.luck@intel.com \
--cc=yazen.ghannam@amd.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox