On 27/04/2021 16:56, Jan Beulich wrote:
> On 26.04.2021 19:54, Andrew Cooper wrote:
>> VT-x has separate entry/exit control for loading guest/host state. Saving
>> guest state on vmexit is performed unconditionally.
> With the latter I find ...
>
>> --- a/xen/arch/x86/hvm/vmx/vmcs.c
>> +++ b/xen/arch/x86/hvm/vmx/vmcs.c
>> @@ -2014,6 +2014,9 @@ void vmcs_dump_vcpu(struct vcpu *v)
>> printk("RFLAGS=0x%08lx (0x%08lx) DR7 = 0x%016lx\n",
>> vmr(GUEST_RFLAGS), regs->rflags,
>> vmr(GUEST_DR7));
>> + if ( vmentry_ctl & VM_ENTRY_LOAD_GUEST_CET )
>> + printk("SSP = 0x%016lx S_CET = 0x%016lx ISST = 0x%016lx\n",
>> + vmr(GUEST_SSP), vmr(GUEST_S_CET), vmr(GUEST_ISST));
> ... the conditional here a little odd, but I expect the plan is
> to have the various bits all set consistently once actually
> enabling the functionality.
TBH, the general behaviour here is poor.
What happens now, as Xen does use CET itself, is that Xen's values
propagate into guest context, and are written back into the VMCS on
VMExit. There is no way to turn this behaviour off AFAICT.
Therefore, we must not print the guest values when the vCPU isn't
configured for CET, because otherwise we'd be rendering what is actually
Xen state, in the guest state area.
Once a VM is using CET, we'll have both VM_ENTRY_LOAD_GUEST_CET and
VM_EXIT_LOAD_HOST_CET set.
There is theoretically an optimisations to be had for a hypervisor not
using CET, to only use the VM_ENTRY_LOAD_GUEST_CET control and leave
VM_EXIT_LOAD_HOST_CET clear, but getting this optimisation wrong will
leave the VMM running with guest controlled values.
Personally, I think it was be a far safer interface for there only to be
a single bit to control "switch CET state" or not.
~Andrew
