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

[Peter Zijlstra]

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.

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.