From: Sean Christopherson <seanjc@google.com>
To: Ackerley Tng <ackerleytng@google.com>
Cc: Paolo Bonzini <pbonzini@redhat.com>,
Shuah Khan <shuah@kernel.org>,
kvm@vger.kernel.org, linux-kselftest@vger.kernel.org,
linux-kernel@vger.kernel.org, michael.roth@amd.com,
jackyli@google.com, liruxin@google.com, darwinguo@google.com,
jacobhxu@google.com
Subject: Re: [PATCH] KVM: selftests: Make guest_code_xsave more friendly
Date: Mon, 8 Jun 2026 20:08:41 -0700 [thread overview]
Message-ID: <aieDuZi3oMQvdwaK@google.com> (raw)
In-Reply-To: <CAEvNRgHtpFa+HAhPVBvB4=ixUuEW-r_Xh49SHEPktUmHgzYcAw@mail.gmail.com>
On Fri, Jun 05, 2026, Ackerley Tng wrote:
> Sean Christopherson <seanjc@google.com> writes:
> > Uh, so as the comment says, the goal is to stash state before _any_ compiled
> > code runs. Shoving the code into inline asm breaks that. The compiler *probably*
> > won't shove anything before the first inline assembly, but there are absolutely
> > no guarantees. E.g. you're subtly relying on a tail-call optimization to avoid
> > any stack operations. If I force guest_sev_es_code() to be inlined, then the
> > prologue becomes:
> >
> > 0000000000402a10 <guest_code_xsave>:
> > 402a10: 48 83 ec 08 sub $0x8,%rsp
> > 402a14: b8 07 00 00 00 mov $0x7,%eax
> > 402a19: 31 d2 xor %edx,%edx
> > 402a1b: 0f ae 27 xsave (%rdi)
> > 402a1e: b9 31 01 01 c0 mov $0xc0010131,%ecx
> >
> > and we're hosed.
> >
>
> And omg, I thought I was running the tests!!
FWIW, you probably were, I had to force it to be inline via __always_inline.
> >> + "xsave (%0)"
> >> + :
> >> + : "r"(addr)
> >> + : "eax", "edx", "memory"
> >> + );
> >> +}
> >> +
> >>
> >> [...snip...]
> >>
>
> My bad, this patch is such a goof!
>
> I still feel that it'd be nice to allow commenting out functions parts
> of selftests while developing other parts, but let's shelve this for
> now.
I mean, it's always "allowed", but that's firmly "Here be dragons!" territory.
There are any number of things that can go sideways when adding and/or removing
code for development and debug purposes, many of which are far more nefarious
and subtle than obscure compiler errors.
next prev parent reply other threads:[~2026-06-09 3:08 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-06-03 22:55 [PATCH] KVM: selftests: Make guest_code_xsave more friendly Ackerley Tng via B4 Relay
2026-06-03 22:55 ` Ackerley Tng
2026-06-03 23:05 ` Sean Christopherson
2026-06-05 21:45 ` Ackerley Tng
2026-06-09 3:08 ` Sean Christopherson [this message]
2026-06-03 23:05 ` sashiko-bot
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=aieDuZi3oMQvdwaK@google.com \
--to=seanjc@google.com \
--cc=ackerleytng@google.com \
--cc=darwinguo@google.com \
--cc=jackyli@google.com \
--cc=jacobhxu@google.com \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-kselftest@vger.kernel.org \
--cc=liruxin@google.com \
--cc=michael.roth@amd.com \
--cc=pbonzini@redhat.com \
--cc=shuah@kernel.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.