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

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


  • To: Jan Beulich <jbeulich@xxxxxxxx>
  • From: Roger Pau Monné <roger.pau@xxxxxxxxxx>
  • Date: Tue, 17 May 2022 15:45:06 +0200
  • 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-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=FCgELYNiii5OflNmNdqvnabfzbEXNHklRCa1gE+H6NM=; b=e7kqv/0k4G8+hBAqnKrUQgYbhCx14Vw9OGmB23C7eC/1UHpIyxeuB8USV6zBJS79TX5cUGF3gzgIKu9NIwX0142SdNIzw8H/1uon4CpvfMuvozArjyqS/QpSzDrBU9qZrK9Qsut6g7TSK0Qo8VhPixOzOHM9jOg+z8UzFaIfwFs5zDd+S61WaUGEEaxdk6j2blJ75j8AOBDSm5/UIzuTPUG46qZDb7SAYY0MHKUas/fwC1fx3Xo7rkXkjJMG6FIa/fuNMcjDyW3PSpQfKyDk96TjpAIzq6JLQi6wDG7izjhaR+ddFQGLvUKCjNOG8nBIfK//1Kem3UdsKbHHzsadaw==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Dj2dXEr7NIe56KBRywqMKNA0gSm72DycRPoxpowYT7TBw7f+QsZgt0sWBSDqnqJZNdJsi7ZufIX6efH6lBAb3AUauB/usjB/AqbX7YwPeDfDb0U3pEyUCq91DZX/8AcXRBbOxwZPRvTbjnGngggiVoBslh0tWftWnDPvvByL8buNiHpVGDitw+xbap2bC9JwjL48FhoStiYe7I/llWp2FwUDSu31ZVs9YZHU5tmgZ2g0TMOCmCYZJgM5yNZX812xY2YBGxb9eKwPilOYKutgII7iJrelagctv1+KP9/DuhGnly0O1OMvgKSWYbcdjGYUUXqaFl11VFLKuKNg3VHLyw==
  • Authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=citrix.com;
  • Cc: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>, Wei Liu <wl@xxxxxxx>, xen-devel@xxxxxxxxxxxxxxxxxxxx
  • Delivery-date: Tue, 17 May 2022 13:45:24 +0000
  • Ironport-data: A9a23:b0xV06M0d1U9PB7vrR3QlsFynXyQoLVcMsEvi/4bfWQNrUoggjUPx 2MXDDvQbv6MNmT0eYx/bou+oB8PvZ6Hx99kSgto+SlhQUwRpJueD7x1DKtR0wB+jCHnZBg6h ynLQoCYdKjYdleF+lH1dOKJQUBUjclkfJKlYAL/En03FFYMpBsJ00o5wbZk29Ew27BVPivW0 T/Mi5yHULOa82Yc3lI8s8pvfzs24ZweEBtB1rAPTagjUG32zhH5P7pGTU2FFFPqQ5E8IwKPb 72rIIdVXI/u10xF5tuNyt4Xe6CRK1LYFVDmZnF+A8BOjvXez8CbP2lS2Pc0MC9qZzu1c99Z7 /xNk4ONWCoSN7TKn/g9WT94MT4uMvgTkFPHCSDXXc276WTjKyep6dM+SUY8MMsf5/p9BnxI+ boAMjcRYxufhuWwhrWmVu1rgcdlJ87uVG8dkig4kXeFUrB5HdafHs0m5vcBtNs0rtpJEvvEI dIQdBJkbQjaYg0JMVASYH47tLjx3SSjLW0GwL6TjatvzXL89i8o65LCYcrOPdOnStRvnEnN8 woq+Ey8WHn2Lue3yzCI73atje/nhj7gVcQZE7jQ3uFuqE2ewCoUEhJ+fUu2p7y1h1CzX/pbK lcI4Ww+oK4q7kupQ9LhGRqirxa5UgU0XtNRF6gw7lGLw6+MswKBXDBYE3hGdcAss9IwSXoyz FiVktj1BDtp9rqIVXaa8bTSpjS3UcQIEVI/ieY/ZVNty7HeTEsb13ojkv4L/HaJs+DI
  • Ironport-hdrordr: A9a23:LYJCq6r0ESOun9Fk4NVNjBYaV5u5L9V00zEX/kB9WHVpm5Oj+v xGzc5w6farsl0ssREb9uxo9pPwJE800aQFmbX5Wo3SJzUO2VHYVb2KiLGP/9SOIU3DH4JmpM Rdmu1FeafN5DtB/LnHCWuDYrEdKbC8mcjH5Ns2jU0dKz2CA5sQkzuRYTzrdnGeKjM2Z6bQQ/ Gnl7d6TnebCD0qR/X+IkNAc/nIptXNmp6jSRkaByQ/4A3LqT+z8rb1HzWRwx9bClp0sPwf2F mAtza8yrSosvm9xBOZ/2jP765OkN+k7tdYHsSDhuUcNz2poAe1Y4ZKXaGEoVkO0amSwWdvtO OJjwYrPsx15X+UVmapoSH10w2l6zoq42+K8y7tvVLT5ejCAB4qActIgoxUNjHD7VA7gd162K VXm0qEqpt+F3r77WvAzumNcysvulu/oHIkn+JWpWdYS5EiZLhYqpFa1F9JEa0HADnx5OkcYa VT5fnnlbdrmG6hHjDkVjEF+q3uYp1zJGbKfqE6gL3a79AM90oJjXfxx6Qk7wI9HdwGOtx5Dt //Q9VVfYF1P7ErhJ1GdZc8qOuMexvwqEH3QRSvyWqOLtB1B1v977jK3Z4S2MaGPLQ18bpaou WybLofjx95R37T
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>

On Tue, May 17, 2022 at 02:10:29PM +0200, Jan Beulich wrote:
> On 09.05.2022 12:23, Roger Pau Monné wrote:
> > On Fri, May 06, 2022 at 02:15:47PM +0200, Jan Beulich wrote:
> >> On 03.05.2022 10:26, Roger Pau Monne wrote:
> >>> --- a/xen/arch/x86/cpuid.c
> >>> +++ b/xen/arch/x86/cpuid.c
> >>> @@ -541,6 +541,9 @@ static void __init calculate_hvm_max_policy(void)
> >>>           raw_cpuid_policy.basic.sep )
> >>>          __set_bit(X86_FEATURE_SEP, hvm_featureset);
> >>>  
> >>> +    if ( boot_cpu_has(X86_FEATURE_VIRT_SC_MSR_HVM) )
> >>> +        __set_bit(X86_FEATURE_VIRT_SSBD, hvm_featureset);
> >>> +
> >>>      /*
> >>>       * If Xen isn't virtualising MSR_SPEC_CTRL for HVM guests (functional
> >>>       * availability, or admin choice), hide the feature.
> >>
> >> Especially with the setting of VIRT_SSBD below here (from patch 1) I
> >> don't think this can go without comment. The more that the other
> >> instance ...
> >>
> >>> @@ -597,6 +600,13 @@ static void __init calculate_hvm_def_policy(void)
> >>>      guest_common_feature_adjustments(hvm_featureset);
> >>>      guest_common_default_feature_adjustments(hvm_featureset);
> >>>  
> >>> +    /*
> >>> +     * Only expose VIRT_SSBD if AMD_SSBD is not available, and thus
> >>> +     * VIRT_SC_MSR_HVM is set.
> >>> +     */
> >>> +    if ( boot_cpu_has(X86_FEATURE_VIRT_SC_MSR_HVM) )
> >>> +        __set_bit(X86_FEATURE_VIRT_SSBD, hvm_featureset);
> >>> +
> >>>      sanitise_featureset(hvm_featureset);
> >>>      cpuid_featureset_to_policy(hvm_featureset, p);
> >>>      recalculate_xstate(p);
> >>
> >> ... here is about default exposure, so cannot really be extended to
> >> the condition under which this is put in "max" (except that of course
> >> "max" needs to include everything "def" has).
> > 
> > Would you be OK with adding:
> > 
> >     /*
> >      * VIRT_SC_MSR_HVM ensures the selection of SSBD is context
> >      * switched between the hypervisor and guest selected values for
> >      * HVM when the platform doesn't expose AMD_SSBD support.
> >      */
> 
> I'm afraid this doesn't explain what I'm after. In
> calculate_hvm_def_policy() the comment explains why / when the feature
> is exposed by _default_. Taking into account patch 1 (where another
> maximum exposure of the feature was introduced), I'd like the
> comment in calculate_hvm_max_policy() to focus on the difference
> between default and maximum exposure (which could be as simple as "if
> exposed by default, also needs exposing in max, irrespective of the
> further max exposure below(?)").

So something like:

/*
 * When VIRT_SSBD is exposed in the default policy as a result of
 * VIRT_SC_MSR_HVM being set  also needs exposing in the max policy.
 */

Would address your concerns?

Thanks, Roger.



 


Rackspace

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