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

[Roger Pau Monné <roger.pau@xxxxxxxxxx>]

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.