[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH 3/3] x86/VT-x: Enumeration for CET
- To: Jan Beulich <jbeulich@xxxxxxxx>
- From: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
- Date: Tue, 27 Apr 2021 17:27:11 +0100
- Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=citrix.com; dmarc=pass action=none header.from=citrix.com; dkim=pass header.d=citrix.com; arc=none
- Arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=OWOmSjSkEwI1z9Uzn9NpaSo1L4nV4SOTyRWOmQR/87s=; b=PnRCFBO6a6N59gqT9VNtHmNMIv8PEHalBQ21005Egn2ZKaOcbPD5/mdjayr67uB9+PZzetdFQFWckYjmRYSU/wL7rg7rEvv2WN9X75i/QRaMnPl09b0WmMA+6jcXGvEen99itF1g0Sgic6rWYIvstLcMPRQQlqYHHsrRgUtSSpRoSGzDPGtWGNKUwgUCpemBXJhtxhoLxP6i7RFh67PeJEYiYiDPhMPNLI7dwCHe2FQqCjtm2+34XKqAxOWy0wcdIXVdAEGl0NBgGwl/qZFeeKr6/uuEIY6tiZ3Q1B4C43KzdPyFBe22gWFxWH//JRfEmTJFvo0PDUhfZWV6JPLJvQ==
- Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=bwWs2eTAODuv0hJBY6W0uMNBkF9FK2N8nBiaGC5bMnLuaNXsHO2LGLh0JGaeSR6IR/YIe+lH+MXHgs9TXwsOQ9qVIrKbfIlH5HOeRzTWYfLMdmSHpv122wJWfWg9s5gvUiHQz/ARolscqYbgIwXSzLBvmxBKlI1nynllW0l1Y0+nEVaCdg60+HFYiAwwQQfzH5CZIdQvLYnttQTZ3RnvFFyuZCujmZEv36938WcrHtL5iOLERHKB0t0zwZtcE3SpTiJqxjSBiGLzbj9XljBDoZMHpKlQ519OQHDc+3mNAJKBIym3dCLHjfKono0tQ2tGwZu8dminYRVYi+8U3efZ2w==
- Authentication-results: esa4.hc3370-68.iphmx.com; dkim=pass (signature verified) header.i=@citrix.onmicrosoft.com
- Cc: Roger Pau Monné <roger.pau@xxxxxxxxxx>, Wei Liu <wl@xxxxxxx>, Jun Nakajima <jun.nakajima@xxxxxxxxx>, Kevin Tian <kevin.tian@xxxxxxxxx>, Xen-devel <xen-devel@xxxxxxxxxxxxxxxxxxxx>
- Delivery-date: Tue, 27 Apr 2021 16:27:26 +0000
- Ironport-hdrordr: A9a23:rFnuR695HJc3KAYgOvhuk+EKdb1zdoIgy1knxilNYDRIb82VkN 2vlvwH1RnyzA0cQm0khMroAsS9aFnXnKQU3aA6O7C+UA76/Fa5NY0K1/qH/xTMOQ3bstRc26 BpbrRkBLTLZ2RSoM7m7GCDfOoI78KA9MmT69v261dIYUVUZ7p77wF/Yzzrd3FeYAVdH5I2GN 69y6N81lmdUE8aZMi6GXUJNtKrz7H2vanrfAIcAFof4BSO5AnC1JfBDxOa0h0COgk/o4sKzG 6tqW3Ez5Tmid6X4Fv212jf75NZ8eGRt+drNYi3peU+bhnpggasTox9V7OFpyBdmpDS1H8a1O Pijj1lE8Nv627AXmzdm2qT5yDQlAwAxlWn6ViEjWDtqcb0LQhKdfZptMZiXTbyr28D1esMt5 5j7iaimLd8SS7kpmDb4ePFUhl7/3DE2kYKoKoooFF0FbcFZKQ5l/14wGplVK0uMQjd844dHO xnHKjnlYxrWGLfVXzfs2V1qebcJ0gbL1ODSkgGjMSfzyJbqnB/11cZ38wShB47heoAd6U=
- Ironport-sdr: Sd1pSDfj37GY7Oe+pIwBawbygO+D74GEwl+X4ZNRo9BIOBu1OMQcxk90ZIm8eE8QHq+NG180C7 BLRu6bzJ9+18JgqVgM7Emy6Z5SxfWzO2vpikIm9YdzHRgAYXbfptl7Twm+qLel3jMJQkv2nefD iWaaNkEpMf6UyIA8fUbTQhDeHo8qc/+NqXZfYjSriXRCKFLPbdspKgs1GGbouPvNUge0K11THD sVlFsp1TLHmju6yWEDtJosl5Oxs90XFrpI7VmqKw42lchjN9ah52gPIf9rZPWOe8h6+uUFPwhP K/Q=
- List-id: Xen developer discussion <xen-devel.lists.xenproject.org>
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
|
