Re: [PATCH] x86/vmware: Fix hypercall clobbers

[Thomas Gleixner <tglx@glx-um.de>]

On Fri, Jan 30 2026 at 08:46, Josh Poimboeuf wrote:
> On Fri, Jan 30, 2026 at 05:24:02PM +0100, Thorsten Leemhuis wrote:
>> >>> Workarounding QEMU misbehavior from the kernel side by introducing less
>> >>> efficient asm inlines does not sound correct.
>> >>
>> >> Well, fixing bugs right where they are obviously is a good thing.
>> >>
>> >> But well, the problem according to the description quoted below was
>> >> exposed by a change that went into 6.19-rc1 -- which makes it a kernel
>> >> regression that must be fixed in the kernel (ideally before 6.19 is out).
>> >>
>> >> At least from my understanding of Linus point of view on situations like
>> >> that. Or am I mistaken for some reason?
>> >>
>> >> Or is this a case of "we for now assume this is such a corner case that
>> >> nobody else will hit; if we are wrong we'll reconsider".
>> > 
>> > Hm, yes, from that perspective I agree this is a kernel regression that
>> > needs fixed.  We still want Linux to work with older "broken" versions
>> > of qemu that clobber registers.
>> 
>> Josh, what's the status here? From here it looks like nothing happened
>> during the last week. Should we move on with the patch at the start of
>> this thread? Or is "widening the hypercall just for
>> VMWARE_CMD_ABSPOINTER_DATA" as suggested by Alexey elsewhere in this
>> thread a better fix? Or would temporarily reverting aca282ab7e75
>> ("x86/asm: Annotate special section entries") be the best move for now?
>
> I think we still need to go with the original patch at the start of this
> thread.  There's nothing preventing the compiler from doing similar
> optimizations for the other hypercalls.

That's correct, but not a problem as long as the hypercall does not
clobber registers beyond those which are in use for a particular
hypercall, no?

Unfortunately there is no formal specification of the hypercall
(backdoor) ABI available, which VMWare really should provide.

All what's available is the lazy 'fits all sizes' implementation in
open-vm-tools and the optimized kernel variant.

The latter makes it pretty obvious that at least the VMWare hypervisor
is handling it correctly. Otherwise we'd have seen reports by now.

As the issue seems to be restricted to an already identified Qemu bug,
it is overkill to penalize perfectly working systems by making all
hypercalls more expensive than necessary.

So unless there is a compelling argument why the existing hypercall
implementation is broken by design, the trivial one-line fix from Alexey
is addressing the actual root cause (it just needs a big fat comment)
and good enough to cure the regression, no?

Alternatively if you don't trust the QEMU/KVM emulation of the VMWare
backdoor at all then force switch it to the slow path and let VMWare
use the optimized inlines.

Thanks,

        tglx