Message ID | 20211216095421.12871-1-andrew.cooper3@citrix.com (mailing list archive) |
---|---|
Headers | show |
Series | x86: Support PKS | expand |
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