On Fri, Jun 05, 2026, Ackerley Tng wrote: > Sean Christopherson <[email protected]> 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.
