Re: [Xen-devel] [PATCH v2 1/2] x86/AMD: correct certain Fam17 checks

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 17.06.19 at 18:00, <andrew.cooper3@xxxxxxxxxx> wrote:
> On 05/04/2019 15:26, Jan Beulich wrote:
>> Commit 3157bb4e13 ("Add MSR support for various feature AMD processor
>> families") converted certain checks for Fam11 to include families all
>> the way up to Fam17. The commit having no description, it is hard to
>> tell whether this was a mechanical dec->hex conversion mistake, or
>> indeed intended. In any event the NB_CFG handling needs to be restricted
>> to Fam16 and below: Fam17 doesn't really have such an MSR anymore. As
>> per observation it's read-zero / write-discard now, so make PV uniformly
>> (with the exception of pinned Dom0 vCPU-s) behave so, just like HVM
>> already does.
>>
>> Mirror the NB_CFG behavior to MSR_FAM10H_MMIO_CONF_BASE as well, except
>> that here the vendor/model check is kept in place (for now at least).
>>
>> A non-MMCFG extended config space access mechanism still appears to
>> exist, but code to deal with it will need to be written down the road,
>> when it can actually be tested.
>>
>> Reported-by: Pu Wen <puwen@xxxxxxxx>
>> Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx>
>> ---
>> v2: Make NB_CFG read-zero / write-discard for PV DomU, just like HVM has
>>     it already. I've not applied "In principle, Acked-by: Andrew Cooper
>>     <andrew.cooper3@xxxxxxxxxx>".
> 
> I suppose this is slightly better intermediate step.  I guess I'll have
> to do the proper fix of removing MSR_AMD64_NB_CFG from the guest
> emulation paths, where it absolutely doesn't belong.

Well, I'll be curious to see how you will manage to do this without
breaking Dom0-s actually hitting this path. Or else I guess I would
have done so right here.

> Acked-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>

Thanks!

Jan



_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel