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.coop...@citrix.com>
> Signed-off-by: Roger Pau Monné <roger....@citrix.com>
> ---
> 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.
