All of lore.kernel.org
 help / color / mirror / Atom feed
From: Sean Christopherson <seanjc@google.com>
To: sashiko-reviews@lists.linux.dev
Cc: Vitaly Kuznetsov <vkuznets@redhat.com>, kvm@vger.kernel.org
Subject: Re: [PATCH v2 4/4] KVM: selftests: Check VMPTRLD with active eVMCS
Date: Tue, 18 Aug 2026 14:56:17 -0700	[thread overview]
Message-ID: <aoTVAdqoAAuVKi8L@google.com> (raw)
In-Reply-To: <aoSTeLzhaWohymLf@google.com>

On Tue, Aug 18, 2026, Sean Christopherson wrote:
> On Tue, Aug 18, 2026, sashiko-bot@kernel.org wrote:
> > > +	asm volatile(KVM_ASM_SAFE("vmptrld %[pa]")
> > > +		     "\n\tsetna %[failed]"
> > 
> > [Severity: Medium]
> > Will this setna instruction incorrectly evaluate CPU flags?
> > 
> > The KVM_ASM_SAFE macro executes xor %%r9, %%r9 on its success path, which
> > unconditionally clears the Carry Flag (CF=0) and sets the Zero Flag (ZF=1).
> 
> Shame on me, I should know better after dealing with ba5ca5e5e6a1 ("x86/retpoline:
> Don't clobber RFLAGS during srso_safe_ret()").
> 
> Untested, but I think the fix is simply:
> 
> diff --git tools/testing/selftests/kvm/include/x86/processor.h tools/testing/selftests/kvm/include/x86/processor.h
> index 6e6f70035508..119715ffe93f 100644
> --- tools/testing/selftests/kvm/include/x86/processor.h
> +++ tools/testing/selftests/kvm/include/x86/processor.h
> @@ -1318,7 +1318,7 @@ gva_t vm_alloc_stack(struct kvm_vm *vm, int nr_pages);
>         "lea 1f(%%rip), %%r10\n\t"                              \
>         "lea 2f(%%rip), %%r11\n\t"                              \
>         fep "1: " insn "\n\t"                                   \
> -       "xor %%r9, %%r9\n\t"                                    \
> +       "mov $0, %%r9\n\t"                                      \
>         "2:\n\t"                                                \
>         "mov  %%r9b, %[vector]\n\t"                             \
>         "mov  %%r10, %[error_code]\n\t"

Vitaly, I'll send a v3 of this series with a rather large pile of additional
selftests changes.  As often seems to be the case, my desire validate a simple
fix has snowballed...

      reply	other threads:[~2026-08-18 21:56 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-08-18 16:52 [PATCH v2 0/4] KVM: nVMX: Adjust VMPTRLD/VMPTRST behavior with active eVMCS Vitaly Kuznetsov
2026-08-18 16:52 ` [PATCH v2 1/4] KVM: nVMX: Make VMPTRLD result in #UD when eVMCS is used Vitaly Kuznetsov
2026-08-18 17:03   ` sashiko-bot
2026-08-18 16:52 ` [PATCH v2 2/4] KVM: nVMX: Make VMPTRST return eVMCS GPA when it " Vitaly Kuznetsov
2026-08-18 16:52 ` [PATCH v2 3/4] KVM: selftests: Adapt to the updated VMPTRST behavior when eVMCS " Vitaly Kuznetsov
2026-08-18 16:52 ` [PATCH v2 4/4] KVM: selftests: Check VMPTRLD with active eVMCS Vitaly Kuznetsov
2026-08-18 17:05   ` sashiko-bot
2026-08-18 17:16     ` Sean Christopherson
2026-08-18 21:56       ` Sean Christopherson [this message]

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=aoTVAdqoAAuVKi8L@google.com \
    --to=seanjc@google.com \
    --cc=kvm@vger.kernel.org \
    --cc=sashiko-reviews@lists.linux.dev \
    --cc=vkuznets@redhat.com \
    /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.