On Wed, Oct 28, 2026 at 4:27 AM Peter Zijlstra <[email protected]> wrote: > > On Thu, Sep 03, 2026 at 12:07:20PM -0400, Zack Rusin wrote: > > The high-bandwidth hypercall helpers push %ebp before loading the in6 > > operand into it. On i386 without frame pointers, both GCC and Clang can > > address the memory-constrained operand relative to %esp. The push then > > moves the stack and the helpers load the wrong value. > > > > Typical i386 configurations use the frame-pointer unwinder and happen to > > address the operand through %ebp. However, UNWINDER_GUESS is available > > with EXPERT and permits the affected frame-pointer-disabled configuration. > > vmwgfx is also available on i386 and calls both helpers. > > > > Stage in6 through %eax before changing either stack register, then save > > %ebp and copy the staged value into it. Load the VMware magic immediately > > before the string I/O instruction. Mark %eax early-clobber so it cannot > > also provide in6 or an address register for it. Use the same sequence on > > x86-64, where the full-width register preserves in6. > > > > Fixes: 34bf25e820ae ("x86/vmware: Introduce VMware hypercall API") > > Cc: [email protected] # 6.11+ > > Signed-off-by: Zack Rusin <[email protected]> > > --- > > So I despise all these hypercalls that muck about with the [BS]P > registers. The Intel function call convention is much older than any of > them and yet they chose to violate it.
Personally I reserve my "despise" for more important things in life, like celery or subscription services but I understand the sentiment. I don't think anyone's here writing love sonnets about this convention. I ranted about this internally in an old man yelling at a sun type of way because existing hosts and guests depend on this layout so "fixing" it would imply adding a new convention and still having to support and fix bugs in this one. > This is both vmware and hyperv. > > If if were just me I'd have nak'ed the lot. But alas. > > At least ARM64 people are (afaik) holding up and telling hyperv its > their problem. Our arm64 conventions don't have this issue ([BS]P just goes through x6 there) our x86 low-bandwidth helpers also don't have it. I have a possible path to fixing this in the kernel (we can't do anything about our hypervisor but you don't care about that) by completely removing the high-bandwidth vmware hypercalls from the kernel but it's a large project and wouldn't help stable. z
smime.p7s
Description: S/MIME Cryptographic Signature
