On 03/05/2021 13:42, Jan Beulich wrote:
> On 30.04.2021 00:12, Andrew Cooper wrote:
>> The sole user of read_pkru() is the emulated pagewalk, and guarded behind
>> guest_pku_enabled() which restricts the path to HVM (hap, even) context only.
>>
>> The commentary in read_pkru() concerning _PAGE_GNTTAB overlapping with
>> _PAGE_PKEY_BITS is only applicable to PV guests.
>>
>> The context switch path, via write_ptbase() unconditionally writes CR4 on any
>> context switch.
>>
>> Therefore, we can guarantee to separate CR4.PKE between PV and HVM context at
>> no extra cost.  Set PKE in mmu_cr4_features on boot, so it becomes set in HVM
>> context, and clear it in pv_make_cr4().
>>
>> Rename read_pkru() to rdpkru() now that it is a simple wrapper around the
>> instruction.  This saves two CR4 writes on every pagewalk, which typically
>> occur more than one per emulation.
>>
>> Signed-off-by: Andrew Cooper <andrew.coop...@citrix.com>
>> ---
>> CC: Jan Beulich <jbeul...@suse.com>
>> CC: Roger Pau Monné <roger....@citrix.com>
>> CC: Wei Liu <w...@xen.org>
>>
>> It also occurs to me that for HVM/Idle => HVM/Idle context switches, we never
>> need to change CR4.  I think this is substantially clearer following XSA-293 
>> /
>> c/s b2dd00574a4f ("x86/pv: Rewrite guest %cr4 handling from scratch") which
>> introduced pv_make_cr4().
> Never needing to change CR4 doesn't uniformly mean writes can be avoided.
> Part of the purpose of the writes is to flush the TLB. Per-domain as well
> as shadow mappings may be in need of such if global mappings are used
> anywhere.

Per domain are not global.  Shadows from HVM guests are a) surely not
global given their changeability, and b) in a non-root TLB tag.

Details like this do need checking, but it shouldn't be hard to improve
on what we've currently got.

~Andrew


Reply via email to