All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ross Lagerwall <ross.lagerwall@citrix.com>
To: chunjie.zhu@citrix.com
Cc: andrew.cooper3@citrix.com, jason.andryuk@amd.com,
	jbeulich@suse.com, roger@xenproject.org, teddy.astie@vates.tech,
	xen-devel@lists.xenproject.org
Subject: Re: [PATCH v2 2/2] x86/nestedsvm: honour L2's EFLAGS.IF when L1 clears V_INTR_MASKING
Date: Tue, 10 Nov 2026 17:03:38 +0000	[thread overview]
Message-ID: <ee9fbfcd-04d2-4e02-8f80-efb850289c30@citrix.com> (raw)
In-Reply-To: <20261110085721.419366-3-chunjie.zhu@citrix.com>

On 11/10/26 8:57 AM, chunjie.zhu@citrix.com wrote:
> From: Chunjie Zhu <chunjie.zhu@citrix.com>
> 
> L0 always runs L2 with V_INTR_MASKING set, so a physical interrupt exits to
> L0 regardless of L2's EFLAGS.IF.  nsvm_intr_blocked() only blocks when L1
> requested V_INTR_MASKING=1 and L1's IF was clear.  With V_INTR_MASKING=0
> and L2's IF clear, nestedsvm_vcpu_interrupt() would still inject
> VMEXIT(INTR) into L1.
> 
> Per the APM (vol.2 rev 3.44 "Physical Interrupt Masking in EFLAGS"), with
> V_INTR_MASKING=0 L2's IF masks physical interrupts, and a masked interrupt
> must stay pending.  Return NSVM_INTR_MASKED for external interrupts in
> that case.
> 
> Signed-off-by: Chunjie Zhu <chunjie.zhu@citrix.com>
> ---
> v2:
>   * Move the check into nsvm_intr_blocked(), as suggested by Ross.
> 
>   xen/arch/x86/hvm/svm/nestedsvm.c | 12 ++++++++++--
>   1 file changed, 10 insertions(+), 2 deletions(-)
> 
> diff --git a/xen/arch/x86/hvm/svm/nestedsvm.c b/xen/arch/x86/hvm/svm/nestedsvm.c
> index a93681e9bbcd..e3b2d20ffce2 100644
> --- a/xen/arch/x86/hvm/svm/nestedsvm.c
> +++ b/xen/arch/x86/hvm/svm/nestedsvm.c
> @@ -1222,8 +1222,16 @@ enum hvm_intblk cf_check nsvm_intr_blocked(struct vcpu *v)
>       {
>           struct vmcb_struct *n2vmcb = nv->nv_n2vmcx;
>   
> -        if ( svm->ns_hostflags.fields.vintrmask &&
> -             !svm->ns_hostflags.fields.rflagsif )
> +        /*
> +         * With V_INTR_MASKING, L1's EFLAGS.IF masks physical interrupts.
> +         * Without it, L2's EFLAGS.IF does (APM vol.2 rev 3.44 "Physical
> +         * Interrupt Masking in EFLAGS"); L0 always runs L2 with
> +         * V_INTR_MASKING set, so the interrupt would otherwise exit to L0
> +         * and be forwarded to L1 even with L2's IF clear.
> +         */
> +        if ( svm->ns_hostflags.fields.vintrmask
> +             ? !svm->ns_hostflags.fields.rflagsif
> +             : !(guest_cpu_user_regs()->eflags & X86_EFLAGS_IF) )
>               return hvm_intblk_rflags_ie;
>   
>           /* when l1 guest passes its devices through to the l2 guest

This only works if the function is called with v == current. I think it
is, but it should probably have an assert to confirm this (like
hvm_interrupt_blocked()).

Also note that this series needs rebasing on top of the latest staging
since it doesn't apply cleanly.

Ross


  reply	other threads:[~2026-11-10 17:04 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-10-16 10:00 [PATCH v1] x86/nestedsvm: honour L2's EFLAGS.IF when L1 clears V_INTR_MASKING chunjie.zhu
2026-10-29 17:20 ` Ross Lagerwall
2026-11-03 10:11   ` chunjie.zhu
2026-11-03 17:07     ` Ross Lagerwall
2026-11-10  8:57 ` [PATCH v2 0/2] " chunjie.zhu
2026-11-10  8:57 ` [PATCH v2 1/2] x86/hvm: don't let EFLAGS.IF block NMI/#MC due to nested state chunjie.zhu
2026-11-10 16:58   ` Ross Lagerwall
2026-11-10 17:36   ` Ross Lagerwall
2026-11-10  8:57 ` [PATCH v2 2/2] x86/nestedsvm: honour L2's EFLAGS.IF when L1 clears V_INTR_MASKING chunjie.zhu
2026-11-10 17:03   ` Ross Lagerwall [this message]
2026-11-12 11:35     ` [PATCH v3 0/3] x86/hvm: fix EFLAGS.IF handling of pending events with nested virt chunjie.zhu
2026-11-12 11:35       ` [PATCH v3 1/3] x86/hvm: don't let EFLAGS.IF block NMI/#MC due to nested state chunjie.zhu
2026-11-12 11:35       ` [PATCH v3 2/3] x86/nestedsvm: honour L2's EFLAGS.IF when L1 clears V_INTR_MASKING chunjie.zhu
2026-11-12 11:35       ` [PATCH v3 3/3] x86/hvm: don't let EFLAGS.IF block #MC in hvm_interrupt_blocked chunjie.zhu
2026-11-12 14:15         ` Jan Beulich

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=ee9fbfcd-04d2-4e02-8f80-efb850289c30@citrix.com \
    --to=ross.lagerwall@citrix.com \
    --cc=andrew.cooper3@citrix.com \
    --cc=chunjie.zhu@citrix.com \
    --cc=jason.andryuk@amd.com \
    --cc=jbeulich@suse.com \
    --cc=roger@xenproject.org \
    --cc=teddy.astie@vates.tech \
    --cc=xen-devel@lists.xenproject.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.