On Wed, Nov 13, 2024 at 04:03:11AM +0800, Edgecombe, Rick P wrote: >On Tue, 2024-11-12 at 08:33 +0800, Chao Gao wrote: >> > >> > Or me, if Intel can't conjure up the resource. I have spent way, way too >> > much >> > time and effort on CET virtualization to let it die on the vine :-) >> >> Just FYI, I will take it over; I plan to submit v11 after x86 fpu changes [*] >> are settled. >> >> [*]: >> https://lore.kernel.org/kvm/67c5a358-0e40-4b2f-b679-33dd0dfe73fb@xxxxxxxxx/ > >This series has some CET intersection: >https://lore.kernel.org/kvm/20241001050110.3643764-13-xin@xxxxxxxxx/ > >Have you checked if there needs to be any changes to either? The intersection was already discussed at https://lore.kernel.org/kvm/496a337d-a20d-4122-93a9-1520779c6d2d@xxxxxxxxx/ The plan is to merge the CET KVM series first. Then, the FRED KVM series will address the intersection by: 1. Allowing guest access to the IA32_FRED_SSP0 MSR if either FRED or CET is exposed to the guest. 2. Intercepting the IA32_FRED_SSP0 MSR if CET is not exposed to the guest. This way, every access to that MSR is trapped and emulated by KVM when only FRED is exposed. Then KVM needn't manually save that MSR or save it through the CET_S XSAVE state when the vCPU is being scheduled out.
