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

Re: [PATCH 2/2] x86/vmx: implement Notify VM Exit


  • To: xen-devel@xxxxxxxxxxxxxxxxxxxx
  • From: Roger Pau Monné <roger.pau@xxxxxxxxxx>
  • Date: Tue, 17 May 2022 16:55:20 +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=iDZnyFFx/un2sZYeX0Dlyxo3VWrtVg/a60ehaCFG/gA=; b=R1YJi5+euPmm+uRIY+fS9qYYPoDFTvey8g4TeUvHQcVxWrxxRQgrfigTLfkaFiIiTUd0aieyMEFQRXWSEoC2KquETWYxcemoIKeSEoxfiZ+VfDjX6QPNzgXXIPVwmQsxPWmQlFK+OGpCU5Y73ZDwZsgw94jluxxaIjyP54phSpB2Dq/RM0CzQpN/3N7bWox77Uv9RSec3W0nzW5k3dojnJFw/6cDTeF+beuMsa0F9wpC3HONYZ8jgcMZHryl4qS6/HBC0tnLg+5In21l/0THQGHEF+OMT8lHduX8q10WzsJxW6F4Jf4N0pVY3b3CX9o2F537HwvdvjkIdWVJTijeBA==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=T3IJsTn6nHapuws2uqXuqRv1ZU/8CcdUKuKRjorfRBNSZm7Ci8LoReL1rdVmDQWIR4OMPrY3vYvgTRWyU0SStVhXdFkGVaPnrbFBmDvz0LPjzJleGTluX1E1Vnnlf4ArK6X2UF5Bs3H5zkWHnml3RkyanqMc791d3Y0nnUrujvr0T/vJRWhNlpaagtXdR+pkZ0l/cUOXqNxYBKEUh2VaWKrUiKDawHc+dRYkdiz1l/hEj337iBPm4HTgCr6Zo3s9WZsHXi34UlswQWoe1uOumoizrPRXZQhup/bYd1vMdFHER/cLZryh4RFnsUf0oZzwNz1vm5xdj6F7pT6rIN80Qg==
  • Authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=citrix.com;
  • Cc: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>, George Dunlap <george.dunlap@xxxxxxxxxx>, Jan Beulich <jbeulich@xxxxxxxx>, Julien Grall <julien@xxxxxxx>, Stefano Stabellini <sstabellini@xxxxxxxxxx>, Wei Liu <wl@xxxxxxx>, Jun Nakajima <jun.nakajima@xxxxxxxxx>, Kevin Tian <kevin.tian@xxxxxxxxx>
  • Delivery-date: Tue, 17 May 2022 14:55:44 +0000
  • Ironport-data: A9a23:gqHx3ayvSPFzAp/E9H96t+f1xyrEfRIJ4+MujC+fZmUNrF6WrkVWy WYcCGyOOPnbNGT3eYx1YYm0/UgHvcSBzIUwQQE9pCAxQypGp/SeCIXCJC8cHc8zwu4v7q5Dx 59DAjUVBJlsFhcwnj/0bv656yMUOZigHtIQMsadUsxKbVIiGX5JZS5LwbZj2NY12IfhWWthh PupyyHhEA79s9JLGjp8B5Kr8HuDa9yr5Vv0FnRnDRx6lAe2e0s9VfrzFonoR5fMeaFGH/bSe gr25OrRElU1XfsaIojNfr7TKiXmS1NJVOSEoiI+t6OK2nCuqsGuu0qS2TV1hUp/0l20c95NJ Npl6LCIay54BIz1x6cEDToEOTNPGPF89+qSSZS/mZT7I0zuVVLJmq8rKX5seIoS96BwHH1E8 uEeJHYVdBefiumqwbW9DO5xmsAkK8qtN4Qa0p1i5WiBUbB6HtadHeOWvLe03x9p7ixKNezZa McDLyJmcTzLYgFVO0dRA5U79AutriamImUB9w3LzUYxy0LLwy9xzofJC/3EVc2kXcoMhB2Gt n2TqgwVBTlfbrRz0wGt4n+qw+PCgy7/cIYTD6GjsO5nhkWJwW4eAwFQUkG0ydG7gEOjX9NUK 2QP5zEj66M18SSDTMT5XhC+iG6JuFgbQdU4O/Yh9AiHx67Q4gCYLmsJVDhMbJohrsBebSMu/ k+EmZXuHzMHmL+ITzSb/7SdrzK3MAAUK3MPYWkPSg5ty9ruvoA1yA7OR9BLEaipg9mzEjb1q w1mtwA7jrQXyMsUjaOy+Amdhyr2/sSQCAko+g/QQ2SpqBtjY5KobJCp7l6d6utcKIGeTR+Ku 31sd9Wi0d3ixKqlzESlKNjh1pnzu55p7BW0bYZTIqQc
  • Ironport-hdrordr: A9a23:Le6mW6hIVi5JRdaJTfB/YfKSNnBQX1N13DAbv31ZSRFFG/FwyP rCoB1L73XJYWgqM03I+eruBEBPewK4yXdQ2/hoAV7EZnichILIFvAa0WKG+VHd8kLFltK1uZ 0QEJSWTeeAd2SS7vyKnzVQcexQp+VvmZrA7Ym+854ud3ANV0gJ1XYENu/xKDwTeOApP+taKH LKjfA32gZINE5nJvhSQRI+Lpv+juyOsKijTQ8NBhYh5gXLpTS06ITiGxzd+hsFSTtAzZor7G CAymXCl++emsD+7iWZ+37Y7pxQltek4txfBPaUgsxQDjn3kA6naKloRrXHljEop+OE7kosjb D30lwdFvU2z0mUUnC+oBPr1QWl+DEy60X6wVvdunfnqdyRfkNMN+NxwaZiNjfJ4Uspu99xlI hR2XiCipZRBRTc2Azg+tnhTXhR5wSJiEtntdRWo21UUIMYZrMUh5cY5llpHJAJGz+/wJw7Ed NpENrX6J9tABynhkjizylSKeGXLzcO9k/seDlBhiXV6UkboJlB9TpY+CRF9U1wsa7USPF/lp D52+pT5fVzp/QtHNNA7dc6MLWK41P2MGLx2UKpUCLa/fI8SjvwQ6Ce2sRG2MiaPLo18bAVpL PtFHtliE9aQTOaNSTJ5uwHzizw
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>

On Tue, May 17, 2022 at 03:21:30PM +0200, Roger Pau Monne wrote:
> Under certain conditions guests can get the CPU stuck in an infinite
> loop without the possibility of an interrupt window to occur.  This
> was the case with the scenarios described in XSA-156.
> 
> Make use of the Notify VM Exit mechanism, that will trigger a VM Exit
> if no interrupt window occurs for a specified amount of time.  Note
> that using the Notify VM Exit avoids having to trap #AC and #DB
> exceptions, as Xen is guaranteed to get a VM Exit even if the guest
> puts the CPU in a loop without an interrupt window, as such disable
> the intercepts if the feature is available and enabled.
> 
> Setting the notify VM exit window to 0 is safe because there's a
> threshold added by the hardware in order to have a sane window value.
> 
> Suggested-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
> Signed-off-by: Roger Pau Monné <roger.pau@xxxxxxxxxx>
> ---
> This change enables the notify VM exit by default, KVM however doesn't
> seem to enable it by default, and there's the following note in the
> commit message:
> 
> "- There's a possibility, however small, that a notify VM exit happens
>    with VM_CONTEXT_INVALID set in exit qualification. In this case, the
>    vcpu can no longer run. To avoid killing a well-behaved guest, set
>    notify window as -1 to disable this feature by default."
> 
> It's not obviously clear to me whether the comment was meant to be:
> "There's a possibility, however small, that a notify VM exit _wrongly_
> happens with VM_CONTEXT_INVALID".
> 
> It's also not clear whether such wrong hardware behavior only affects
> a specific set of hardware, in a way that we could avoid enabling
> notify VM exit there.
> 
> There's a discussion in one of the Linux patches that 128K might be
> the safer value in order to prevent false positives, but I have no
> formal confirmation about this.  Maybe our Intel maintainers can
> provide some more feedback on a suitable notify VM exit window
> value.
> 
> I've tested with 0 (the proposed default in the patch) and I don't
> seem to be able to trigger notify VM exits under normal guest
> operation.  Note that even in that case the guest won't be destroyed
> unless the context is corrupt.
> ---
>  docs/misc/xen-command-line.pandoc       | 11 +++++++++++
>  xen/arch/x86/hvm/vmx/vmcs.c             | 20 +++++++++++++++++++-
>  xen/arch/x86/hvm/vmx/vmx.c              | 24 ++++++++++++++++++++++++
>  xen/arch/x86/include/asm/hvm/vmx/vmcs.h |  4 ++++
>  xen/arch/x86/include/asm/hvm/vmx/vmx.h  |  6 ++++++
>  xen/arch/x86/include/asm/perfc_defn.h   |  3 ++-
>  6 files changed, 66 insertions(+), 2 deletions(-)
> 
> diff --git a/docs/misc/xen-command-line.pandoc 
> b/docs/misc/xen-command-line.pandoc
> index 1dc7e1ca07..ccf8bf5806 100644
> --- a/docs/misc/xen-command-line.pandoc
> +++ b/docs/misc/xen-command-line.pandoc
> @@ -2544,6 +2544,17 @@ guest will notify Xen that it has failed to acquire a 
> spinlock.
>  <major>, <minor> and <build> must be integers. The values will be
>  encoded in guest CPUID 0x40000002 if viridian enlightenments are enabled.
>  
> +### vm-notify-window (Intel)
> +> `= <integer>`
> +
> +> Default: `0`
> +
> +Specify the value of the VM Notify window used to detect locked VMs. Set to 
> -1
> +to disable the feature.  Value is in units of crystal clock cycles.

The following chunk is missing in order for -1 to disable the feature:

diff --git a/xen/arch/x86/hvm/vmx/vmcs.c b/xen/arch/x86/hvm/vmx/vmcs.c
index 5685a5523e..817e644d09 100644
--- a/xen/arch/x86/hvm/vmx/vmcs.c
+++ b/xen/arch/x86/hvm/vmx/vmcs.c
@@ -1110,6 +1110,10 @@ static int construct_vmcs(struct vcpu *v)
           SECONDARY_EXEC_ENABLE_VM_FUNCTIONS |
           SECONDARY_EXEC_ENABLE_VIRT_EXCEPTIONS);

+    if ( vm_notify_window < 0 )
+        v->arch.hvm.vmx.secondary_exec_control &=
+            ~SECONDARY_EXEC_NOTIFY_VM_EXITING;
+
     if ( paging_mode_hap(d) )
     {
         v->arch.hvm.vmx.exec_control &= ~(CPU_BASED_INVLPG_EXITING |

Thanks, Roger.



 


Rackspace

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