On 21/12/2021 12:18 pm, Jan Beulich wrote:
> On 16.12.2021 10:54, Andrew Cooper wrote:
>> With all infrastructure in place, advertise the PKS CPUID bit to guests, and
>> let them set CR4.PKS.
>>
>> Experiment with a tweak to the layout of hvm_cr4_guest_valid_bits() so future
>> additions will be just a single added line.
>>
>> The current context switching behaviour is tied to how VT-x works, so leave a
>> safety check in the short term.
>>
>> Signed-off-by: Andrew Cooper <andrew.coop...@citrix.com>
> Reviewed-by: Jan Beulich <jbeul...@suse.com>
Thanks.
>
> I would like to ask though that you ...
>
>> --- a/xen/include/public/arch-x86/cpufeatureset.h
>> +++ b/xen/include/public/arch-x86/cpufeatureset.h
>> @@ -244,7 +244,7 @@ XEN_CPUFEATURE(CLDEMOTE, 6*32+25) /*A CLDEMOTE
>> instruction */
>> XEN_CPUFEATURE(MOVDIRI, 6*32+27) /*a MOVDIRI instruction */
>> XEN_CPUFEATURE(MOVDIR64B, 6*32+28) /*a MOVDIR64B instruction */
>> XEN_CPUFEATURE(ENQCMD, 6*32+29) /* ENQCMD{,S} instructions */
>> -XEN_CPUFEATURE(PKS, 6*32+31) /* Protection Key for Supervisor */
>> +XEN_CPUFEATURE(PKS, 6*32+31) /*H Protection Key for Supervisor */
> ... clarify this restriction of not covering shadow mode guests by
> an adjustment to title or description. Aiui the sole reason for
> the restriction is that shadow code doesn't propagate the key bits
> from guest to shadow PTEs?
PKU is only exposed on HAP, so PKS really ought to match.
We indeed don't copy the leaf PKEY into the shadows. While that ought
to be relatively to adjust, we would then have to make sh_page_fault()
cope with seeing PFEC_prot_key.
But honestly, there are far far more important things to spend time on.
~Andrew
