[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH v2 2/3] amd/msr: allow passthrough of VIRT_SPEC_CTRL for HVM guests


  • To: Roger Pau Monné <roger.pau@xxxxxxxxxx>
  • From: Jan Beulich <jbeulich@xxxxxxxx>
  • Date: Mon, 28 Mar 2022 17:26:54 +0200
  • Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=suse.com; dmarc=pass action=none header.from=suse.com; dkim=pass header.d=suse.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-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=EKR7y9OnGypk447IKCrDmq6IHJeppj8YpJA3wSQPChM=; b=n8f1Wn3zDn8/PEBXlhljTdYkqKi/lb6zcwLdchJIrO6QYQKjBgccbOh4WYl4uMzNVl5MfzE7odI+Rv90IKlPh5NYSSmMdobLeQWdip23qXnQhHYkDeCHCse7P4dbBEjuZOE1xdsNa8kC/Xuqu10F+c8z5wl/nYMZuxYS63C4Cck1jB/kIqZObdApasl0zKSLbR/yX5Ph58QLic7FdkmoJk3YsC9ZhdtUx+rboy3RYvJVC8T9DDvQ6dMYlMSHHiQGVE4HeI9Yz775cCI2L0D48EZot+oXvOA26VZ817k9ppZDxx94IGDealgTwr93hkVnDTrB0RYki726DKqEcRji0A==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=KL8p3xkPlRluLzR1Y/6QzF8OGs/zg8Urw/FdcJdZq/EGO++ptPFu3qdu6L1lv+66bsifxs7w+DTvKHU1q1QN+q+n0W+e/VHfOJ79CfSdwXM7dkTyxkbVEPdENzkeOaoQdpc1GOmMGEbx9vRJyOkunRcEn/W5ZJUumDXes5+sDxZCzQfzrzI5WJU9zKqQ4HDBbGNQeDwHmr+lEH0EBiOUxiw5sCsbuZRDSpyhs+RwsnZx1nxLhNsaSdV87S20Sal/nIXzvB0NRL7j1IyWjLbCrhg2s/yulIyG7PY1b8i4wg84rEGcmNHMR5pOXULifR6z2GjBp5SkK5mNZM/F5A5z9w==
  • Authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=suse.com;
  • Cc: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>, Wei Liu <wl@xxxxxxx>, xen-devel@xxxxxxxxxxxxxxxxxxxx
  • Delivery-date: Mon, 28 Mar 2022 15:27:05 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>

On 28.03.2022 17:19, Roger Pau Monné wrote:
> On Mon, Mar 28, 2022 at 04:02:40PM +0200, Jan Beulich wrote:
>> On 15.03.2022 15:18, Roger Pau Monne wrote:
>>> Allow HVM guests untrapped access to MSR_VIRT_SPEC_CTRL if the
>>> hardware has support for it. This requires adding logic in the
>>> vm{entry,exit} paths for SVM in order to context switch between the
>>> hypervisor value and the guest one. The added handlers for context
>>> switch will also be used for the legacy SSBD support.
>>>
>>> Introduce a new synthetic feature leaf (X86_FEATURE_VIRT_SC_MSR_HVM)
>>> to signal whether VIRT_SPEC_CTRL needs to be handled on guest
>>> vm{entry,exit}.
>>>
>>> Note the change in the handling of VIRT_SSBD in the featureset
>>> description. The change from 's' to 'S' is due to the fact that now if
>>> VIRT_SSBD is exposed by the hardware it can be passed through to HVM
>>> guests.
>>
>> But lower vs upper case mean "(do not) expose by default", not whether
>> underlying hardware exposes the feature. In patch 1 you actually used
>> absence in underlying hardware to justify !, not s.
> 
> Maybe I'm getting lost with all this !, lower case and upper case
> stuff.
> 
> Patch 1 uses '!s' to account for:
>  * '!': the feature might be exposed to guests even when not present
>    on the host hardware.
>  * 's': the feature won't be exposed by default.
> 
> Which I think matches what is implemented in patch 1 where VIRT_SSBD
> is possibly exposed to guest when running on hardware that don't
> necessarily have VIRT_SSBD (ie: because we use AMD_SSBD in order to
> implement VIRT_SSBD).
> 
> Patch 2 changes the 's' to 'S' because this patch introduces support
> to expose VIRT_SSBD to guests by default when the host (virtual)
> hardware also supports it.

Hmm, so maybe the wording in the description is merely a little
unfortunate.

>>> @@ -610,6 +611,14 @@ static void cf_check svm_cpuid_policy_changed(struct 
>>> vcpu *v)
>>>      svm_intercept_msr(v, MSR_SPEC_CTRL,
>>>                        cp->extd.ibrs ? MSR_INTERCEPT_NONE : 
>>> MSR_INTERCEPT_RW);
>>>  
>>> +    /*
>>> +     * Give access to MSR_VIRT_SPEC_CTRL if the guest has been told about 
>>> it
>>> +     * and the hardware implements it.
>>> +     */
>>> +    svm_intercept_msr(v, MSR_VIRT_SPEC_CTRL,
>>> +                      cp->extd.virt_ssbd && cpu_has_virt_ssbd ?
>>
>> Despite giving the guest direct access guest_{rd,wr}msr() can be hit
>> for such guests. Don't you need to update what patch 1 added there?
> 
> Indeed, I should add the chunk that's added in the next patch.
> 
>> Also, is there a reason the qualifier here is not in sync with ...
>>
>>> @@ -3105,6 +3114,36 @@ void svm_vmexit_handler(struct cpu_user_regs *regs)
>>>      vmcb_set_vintr(vmcb, intr);
>>>  }
>>>  
>>> +/* Called with GIF=0. */
>>> +void vmexit_virt_spec_ctrl(void)
>>> +{
>>> +    unsigned int val = opt_ssbd ? SPEC_CTRL_SSBD : 0;
>>> +
>>> +    if ( cpu_has_virt_ssbd )
>>
>> ... this one? Since the patching is keyed to VIRT_SC_MSR_HVM, which in
>> turn is enabled only when cpu_has_virt_ssbd, it would seem to me that
>> if any asymmetry was okay here, then using cp->extd.virt_ssbd without
>> cpu_has_virt_ssbd.
> 
> Using just cp->extd.virt_ssbd will be wrong when next patch also
> introduces support for exposing VIRT_SSBD by setting SSBD using the
> non-architectural method.

Well, if the next patch needs to make adjustments here, then that's
fine but different from what's needed at this point. However, ...

> We need to context switch just based on cpu_has_virt_ssbd because the
> running guest might not get VIRT_SSBD offered (cp->extd.virt_ssbd ==
> false) but Xen might be using SSBD itself so it needs to context
> switch in order to activate it. Ie: if !cp->extd.virt_ssbd then the
> guest will always run with SSBD disabled, but Xen might not.

... yes, I see.

> Hope all this makes sense,

It does, and ...

> I find it quite complex due to all the interactions.

... yes, I definitely agree.

Jan




 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.