mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Alexey Makhalov <alexey.makhalov@broadcom.com>
To: Linus Torvalds <torvalds@linux-foundation.org>,
	Josh Poimboeuf <jpoimboe@kernel.org>
Cc: Thomas Gleixner <tglx@glx-um.de>,
	Thorsten Leemhuis <regressions@leemhuis.info>,
	x86@kernel.org, linux-kernel@vger.kernel.org,
	Ajay Kaher <ajay.kaher@broadcom.com>,
	bcm-kernel-feedback-list@broadcom.com,
	Peter Zijlstra <peterz@infradead.org>,
	Justin Forbes <jforbes@fedoraproject.org>,
	Linux kernel regressions list <regressions@lists.linux.dev>
Subject: Re: [PATCH] x86/vmware: Fix hypercall clobbers
Date: Fri, 6 Feb 2026 14:41:51 -0800	[thread overview]
Message-ID: <a78c4922-e355-4b85-a1aa-9aa3cc3dfca0@broadcom.com> (raw)
In-Reply-To: <CAHk-=wivx7pi+h+hGmvNFAJm6StQLiQ-b8DdsE5J=LMOWae8Ng@mail.gmail.com>



On 2/6/26 9:19 AM, Linus Torvalds wrote:
> 
> 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.
> 
Thanks, Linus, for the suggestion.

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

  parent reply	other threads:[~2026-02-06 22:41 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-01-22  3:18 Josh Poimboeuf
2026-01-22 10:00 ` Alexey Makhalov
2026-01-22 17:40   ` Josh Poimboeuf
2026-01-23  9:47   ` Thorsten Leemhuis
2026-01-23 17:35     ` Josh Poimboeuf
2026-01-30 16:24       ` Thorsten Leemhuis
2026-01-30 16:46         ` Josh Poimboeuf
2026-02-06 10:07           ` Thomas Gleixner
2026-02-06 16:32             ` Josh Poimboeuf
2026-02-06 17:19               ` Linus Torvalds
2026-02-06 19:08                 ` Josh Poimboeuf
2026-02-06 19:57                   ` Linus Torvalds
2026-02-06 22:24                     ` Josh Poimboeuf
2026-02-06 22:38                       ` Linus Torvalds
2026-02-06 23:08                         ` Linus Torvalds
2026-02-07  0:46                           ` Josh Poimboeuf
2026-02-07  1:05                             ` Linus Torvalds
2026-02-12 14:54                           ` Paolo Bonzini
2026-02-06 22:41                 ` Alexey Makhalov [this message]
2026-01-24  1:01     ` Alexey Makhalov
2026-01-24  6:27       ` Thorsten Leemhuis

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=a78c4922-e355-4b85-a1aa-9aa3cc3dfca0@broadcom.com \
    --to=alexey.makhalov@broadcom.com \
    --cc=ajay.kaher@broadcom.com \
    --cc=bcm-kernel-feedback-list@broadcom.com \
    --cc=jforbes@fedoraproject.org \
    --cc=jpoimboe@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=peterz@infradead.org \
    --cc=regressions@leemhuis.info \
    --cc=regressions@lists.linux.dev \
    --cc=tglx@glx-um.de \
    --cc=torvalds@linux-foundation.org \
    --cc=x86@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®