>>> On 17.06.19 at 18:00, <andrew.coop...@citrix.com> 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 <pu...@hygon.cn>
>> Signed-off-by: Jan Beulich <jbeul...@suse.com>
>> ---
>> 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.coop...@citrix.com>".
>
> 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.coop...@citrix.com>
Thanks!
Jan
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
