Re: [PATCH v1] x86/vmware: Fix i386 high-bandwidth hypercall arguments

[Zack Rusin]

On Wed, Oct 28, 2026 at 4:27 AM Peter Zijlstra <peterz@xxxxxxxxxxxxx> 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: stable@xxxxxxxxxxxxxxx # 6.11+
> > Signed-off-by: Zack Rusin <zack.rusin@xxxxxxxxxxxx>
> > ---
>
> 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

Attachment: smime.p7s
Description: S/MIME Cryptographic Signature