[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:53:43 +0200
  • Authentication-results: esa3.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:53:54 +0000
  • Ironport-sdr: OQQ5Bj61Joo2u0n1y9MxhU9w3ctQJfTi3aY0gwV5gFj3B01MwcjnWauRlM3SbsoSaWQLxYdZio U/54aKywxcMFbwrxIZ2/VLX3RZGkz31GlbyjlYYpjWp1UtPxUWeyUyLOiVDKVgxR8OnUdZDfAM oDlGdbAtLyE3PWzDxrwSO1682n/J9B9mg+5TMoSAqVbEB+PfN+mUJtlQRhZRY1eQmo0k3qbnyC iJ7uLj4K2o+oOhsWcC+yS/kF01DaGpFfu1q4gdvrzJf3kqGIg19DZk7vwDLol1juseOCDi8KFy PwM=
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>

On Wed, Sep 16, 2020 at 03:28:28PM +0200, Jan Beulich wrote:
> On 16.09.2020 15:04, Roger Pau Monné wrote:
> > 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.
> 
> Ah, and it's exclusively this one as it seems. The models 1xh one
> again doesn't have it.
> 
> >>> @@ -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.
> 
> Looking at the sole bit that's defined there, I agree the main reason
> for Win10 to read it would look to be to potentially also write it if
> it finds certain bits unset. If so, perhaps we want to consider to
> report a value with this/these bit(s) set?

So the manual only reports the meaning of bit 54, yet my EPYC system
reports 0x0168000000000000.

> > I can try to return #GP for writes, but I don't see much issue in just
> > ignoring writes.
> 
> The reason for me asking is that I'd prefer if we didn't grow an
> endless list of exceptions for no reason. In fact I wonder whether
> some MSRs that we currently ignore writes for couldn't be dropped.

Let me see if I can make Windows happy by returning either bit 54 as 0
or 1, but given the value on bare metal I'm worried that Windows has
more insight on this value than just bit 54.

Thanks, Roger.



 


Rackspace

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