[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH] x86/svm: ignore accesses to EX_CFG


  • To: Jan Beulich <jbeulich@xxxxxxxx>
  • From: Roger Pau Monné <roger.pau@xxxxxxxxxx>
  • Date: Wed, 16 Sep 2020 15:04:39 +0200
  • Authentication-results: esa2.hc3370-68.iphmx.com; dkim=none (message not signed) header.i=none
  • Cc: <xen-devel@xxxxxxxxxxxxxxxxxxxx>, Andrew Cooper <andrew.cooper3@xxxxxxxxxx>, Wei Liu <wl@xxxxxxx>
  • Delivery-date: Wed, 16 Sep 2020 13:04:53 +0000
  • Ironport-sdr: H4zyf3dZ4GY4fvLrpZDu5Tn5yu9CULnCvCeWIUvoWwWWsY73SfhGpTblv1uCAK4p2Q05l7mdKC 96t8VOoBB15fJojCcCmz66tbLBw5UBITtDe4+yZZ+gM8t/wf667VcaNBvCGellE3tbTiW3ZJKi AzBAu3tZ/8GYubhz4aMGlsMoeSXPNTR+pNflJpqz1B5rUGJij7H3kTKNYE21xINEPVGiHLSuLQ n8WQWLuHwzoJFdtRpgujOVuCFdMghKsWOb6HPfPxci4mFDdb+3AVO+sj+gMM4m87OV00VPzY4U W1Q=
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>

On Wed, Sep 16, 2020 at 02:55:52PM +0200, Jan Beulich wrote:
> On 16.09.2020 12:54, Roger Pau Monne wrote:
> > Windows 10 will try to unconditionally read EX_CFG on AMD hadrware,
> > and injecting a #GP fault will result in a panic:
> > 
> > svm.c:1964:d5v0 RDMSR 0xc001102c unimplemented
> > d5v0 VIRIDIAN CRASH: 7e ffffffffc0000096 fffff8054cbe5ffe fffffa0837a066e8 
> > fffffa0837a05f30
> > 
> > Return 0 when trying to read the MSR and drop writes.
> 
> So I've gone through a bunch of BKDGs and PPRs, without finding
> this MSR mentioned in any of them. Could you point out on which
> model(s) it actually exists? You must have found it somewhere,
> or else you wouldn't know a name for it...

Yes, sorry it took me a while to find it also, and I should have added
a reference here. It's in "BIOS and Kernel Developer’s Guide (BKDG)
for AMD Family 15h Models 00h-0Fh Processors", albeit Windows will try
to access it on Family 17h also.

> > @@ -2108,6 +2109,7 @@ static int svm_msr_write_intercept(unsigned int msr, 
> > uint64_t msr_content)
> >      case MSR_K8_TOP_MEM2:
> >      case MSR_K8_SYSCFG:
> >      case MSR_K8_VM_CR:
> > +    case MSR_AMD64_EX_CFG:
> >          /* ignore write. handle all bits as read-only. */
> >          break;
> 
> Is this necessary, rather than having writes fault?

Hm, I'm not sure about that. This is the same that KVM did to handle
the MSR, see Linux commit 0e1b869fff60c81b510c2d00602d778f8f59dd9a.

I can try to return #GP for writes, but I don't see much issue in just
ignoring writes.

> > --- a/xen/include/asm-x86/msr-index.h
> > +++ b/xen/include/asm-x86/msr-index.h
> > @@ -330,6 +330,7 @@
> >  #define MSR_AMD64_DC_CFG           0xc0011022
> >  #define MSR_AMD64_DE_CFG           0xc0011029
> >  #define AMD64_DE_CFG_LFENCE_SERIALISE      (_AC(1, ULL) << 1)
> > +#define MSR_AMD64_EX_CFG                0xc001102c
> 
> Indentation here wants to match the siblings, i.e. use hard tabs
> (for now). Easily addressed while committing, of course.

Oh, sure, sorry for not realizing.

Thanks, Roger.



 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.