Re: [PATCH] x86/vmware: Fix hypercall clobbers
From: Alexey Makhalov
Date: Fri Feb 06 2026 - 17:42:00 EST
On 2/6/26 9:19 AM, Linus Torvalds wrote:
Thanks, Linus, for the suggestion.
Longer term, we should probably clean this garbage up. The whole "use
inline functions with inline asm" for the vmware case makes zero sense
to begin with. Absolutely nobody cares. This is not
performance-critical code. We should get rid of those inlines in
<asm/vmware.h> *entirely*, and just make vmware_hypercall_slow() be
less of a shit-show.
Make that stupid switch statement in vmware_hypercall_slow() use a
static call, and get rid of the idiotic calling conventions that pass
in ten arguments, of which five are pointers that can be NULL. So
*OF*COURSE* the end result is a steaming pile of sh*t because the
calling convention is just a pile of dung that cannot be dealt with
well.
So make it do something like this instead:
// Called 'in1,3-5' traditionally for bad reasons.
// 'in2' was presumably apparently 'cmd' in cx
// and ax is VMWARE_HYPERVISOR_MAGIC
struct vmware_hypercall_args {
unsigned long bx, dx, si, di;
};
// Called 'out1-5' traditionally for bad reasons.
// 'in0' is returned in ax.
struct vmware_hypercall_results {
unsigned long bx, cx, dx, si, di;
};
unsigned long vmware_hypercall(unsigned long cmd,
const struct vmware_hypercall_args *in,
struct vmware_hypercall_results *out)
{
... do sane code here ...
and I can almost guarantee it's going to be as fast or faster than the
existing crazy inline asm, because it won't have any stupid bad
calling conventions.
Then you can have trivial wrapper functions like
static inline unsigned long vmware_hypercall1(unsigned long
cmd, unsigned long arg)
{
const struct vmware_hypercall_args in = { .bx = arg };
struct vmware_hypercall_results out;
return vmware_hypercall(cmd, &in, &out);
}
and you're damn well done. Wouldn't that be a hell of a lot nicer -
and avoid the existing bug just by virtue of not having that stupid
and pointless "optimziation" where it thinks that si/di might be
useful around the vmware call.
vmware_hypercallX family of functions follows the idea of kvm_hypercallX from <asm/kvm_para.h>. But legacy and variations of possible combinations made it hairy.
Having just one wide hypercall implementation and multiple wrappers will definitely be more readable and maintainable. Questionable about performance though.
I'll work on it.
We will also analyze the possibility of the backdoor deprecation from the Linux kernel side.
--Alexey