I found a spare half hour, and this turned out to go very smoothly.

It's tentatively RFC right now, because I'm still adding PKS support to the
XTF comprehensive pagewalk test, but the series is definitely fit for review
at this point.

Andrew Cooper (6):
  x86/prot-key: Enumeration for Protection Key Supervisor
  x86/prot-key: Split PKRU infrastructure out of asm/processor.h
  x86/hvm: Context switch MSR_PKRS
  x86/hvm: Enable guest access to MSR_PKRS
  x86/pagewalk: Support PKS
  x86/hvm: Support PKS

 tools/libs/light/libxl_cpuid.c              |  1 +
 tools/misc/xen-cpuid.c                      |  2 +-
 xen/arch/x86/cpuid.c                        |  9 +++
 xen/arch/x86/hvm/hvm.c                      |  8 ++-
 xen/arch/x86/hvm/vmx/vmx.c                  | 14 +++++
 xen/arch/x86/include/asm/guest_pt.h         |  5 ++
 xen/arch/x86/include/asm/hvm/hvm.h          |  3 +
 xen/arch/x86/include/asm/msr-index.h        |  2 +
 xen/arch/x86/include/asm/msr.h              |  8 +++
 xen/arch/x86/include/asm/processor.h        | 38 ------------
 xen/arch/x86/include/asm/prot-key.h         | 93 +++++++++++++++++++++++++++++
 xen/arch/x86/include/asm/x86-defns.h        |  1 +
 xen/arch/x86/mm/guest_walk.c                | 16 +++--
 xen/arch/x86/msr.c                          | 17 ++++++
 xen/arch/x86/x86_emulate.c                  |  2 +
 xen/include/public/arch-x86/cpufeatureset.h |  1 +
 16 files changed, 174 insertions(+), 46 deletions(-)
 create mode 100644 xen/arch/x86/include/asm/prot-key.h

-- 
2.11.0

On 16/12/2021 09:54, Andrew Cooper wrote:
> I found a spare half hour, and this turned out to go very smoothly.
>
> It's tentatively RFC right now, because I'm still adding PKS support to the
> XTF comprehensive pagewalk test, but the series is definitely fit for review
> at this point.

I suppose it's worth expanding on this a little.  What I've proposed
here is the most efficient option, and it is very non-invasive but comes
with the downside that Xen can't set CR4.PKS.

It is tied to VT-x behaviour, so I've left a deliberate clobber so it
won't engage automatically if AMD add support on future CPUs.


If we want Xen to be able to use PKS, then a couple of things change.

1) PV32 needs inhibiting.  This is likely the case anyway, due to CET.
2) VT-x will need to start using the PKRS load/save controls
2a) Need new get/set_pkrs hvm_funcs accessors to abstract the
VMREAD/WRITE out of common code.
2b) guest_{rd,wr}msr() and pagewalk updated to cope
3) Whatever AMD needs (if applicable).


In terms of Xen using PKS, the first piece of low hanging fruit is
removing access to the stubs by default, to prevent stray writes from
interfering with other CPUs.

Changing PKEY is a WRMSR, so not the fastest action in the world even if
it is well optimised in microcode, but modification of the stubs is not
a fastpath, so this would be entirely fine.

~Andrew