Re: [Xen-devel] [PATCH v2 3/9] x86/mm: honor opt_pcid also for 32-bit PV domains

[Jan Beulich <jbeulich@xxxxxxxx>]

On 18.09.2019 13:55, Andrew Cooper wrote:
> On 18/09/2019 10:22, Jan Beulich wrote:
>> On 17.09.2019 21:00, Andrew Cooper wrote:
>>> On 17/09/2019 07:14, Jan Beulich wrote:
>>>> I can't see any technical or performance reason why we should treat
>>>> 32-bit PV different from 64-bit PV in this regard.
>>> Well, other than the fact this setting is only read for a 64bit guest...
>> How come? make_cr3() uses it uniformly, as does pv_make_cr4().
>> toggle_guest_mode() is the one case where it's strictly 64-bit
>> guest only.
> 
> Oh - you are right.  I don't know how I came to the above conclusion,
> but ...
> 
>>> The reason it isn't set for 32bit guests is that there is no scenario
>>> where we use it.
>> "pcid=1" and "pcid=noxpti" both are scenarios where, with this
>> patch in place, we would use it.
> 
> ... I still don't see why this is sensible.

Whether it's sensible to at least try out I'm not going to judge.
What I find wrong though is that, for no reason, we don't fully
honor the command line option prior to this change.

> As far as I can tell, all it will do for a 32bit PV guest is start using
> 2 PCIDs for the same logical gCR3, which will be a net perf it hit for
> 32bit PV guests.
> 
> This is ultimately wrapped up in the confusion over TF_kernel_mode and
> v->arch.guest_table{,_user}.

Is there still confusion, despite the cleanup done not overly long
ago? TF_kernel_mode is now uniformly set for HVM and 32-bit PV
vCPU-s; only 64-bit PV vCPU-s can have it clear.

Jan

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