public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
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.

  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