From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-qv1-f97.google.com (mail-qv1-f97.google.com [209.85.219.97]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 0C39F3043D7 for ; Fri, 6 Feb 2026 22:41:57 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.219.97 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1770417718; cv=none; b=HGlt1V1wzx8R2xpdcXHZNwnASDt6MZ4doJd5bYjOf0/HjuKGEKwuUEwaQBCHqaTmkWLIPymfDT95wjYpeXaRM2SI4zY86/oaCY73CbUN5HWBlyf5PxdBE596sMZuglLkSIm7iG09rGD2Z5XZLDEHUjUBSOy/ncs27IZabQuvPg4= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1770417718; c=relaxed/simple; bh=6icuq1HqCjXTHsU3H7PDhItnS001COoVMC0scZGYRoY=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=VTqeSmMi2JJ7tne91IOnMQ2Z34C4sW4Oru7IEDtWBP1uw+SNE8BGwKovawVM3CtK2USWw9bjgHJFNImiTCuAh6LbGySq8+rRQimNN9SpqLWsZ6y06KGzi/HjY6MOgpxstbX1InXihdgiWaMSjOpfw+S38rbF8+RU1qsvohtmPP4= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=broadcom.com; spf=fail smtp.mailfrom=broadcom.com; dkim=pass (1024-bit key) header.d=broadcom.com header.i=@broadcom.com header.b=ABiUBodr; arc=none smtp.client-ip=209.85.219.97 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=broadcom.com Authentication-Results: smtp.subspace.kernel.org; spf=fail smtp.mailfrom=broadcom.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=broadcom.com header.i=@broadcom.com header.b="ABiUBodr" Received: by mail-qv1-f97.google.com with SMTP id 6a1803df08f44-89505dd3e24so34287636d6.1 for ; Fri, 06 Feb 2026 14:41:57 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1770417717; x=1771022517; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:dkim-signature:x-gm-gg:x-gm-message-state:from:to :cc:subject:date:message-id:reply-to; bh=MbTioyKnkYFn3YmIZ+Irbz8xYrMm1V4XqCu/uXGzVWU=; b=jXyZnlfCm9HW0Lw7m0OR3RCxDKvHPA85hGUkoiZCeCkfpnO+hVjtx+z9QfPbDSTlDL mG1Avruydc8ffLEmll1SZaMIfBakJ84piGpqt5Ed89FIEoToo9KKt0uOngiOVMVsM1Bm ONJb3z+z6nz1g/+LCSKO0iXcVFylwbCou755vLqGaHCSJUaI8n+3zwemuxq4JEDzL8hs f+BhpGyKkYMdJ6FdlQDpJNNlivXv1H2DiWqcXvprHdE4mhI7Z5uibhl8wctyEmwW0ZFf TQ3CNkY3bpPkPhxo66Jo2HzUI3tn5lOtmzlkDHHPIlGCBoYZR5KW0TBQegoco4eTdyp6 ib1w== X-Forwarded-Encrypted: i=1; AJvYcCXI9/U9/m6mMvX5HPmQoHhi6MDPlSb8aXgY1sLFylhUik+Zb6pkB4S333odLs68fcJHJhYR22AREL9iozg=@vger.kernel.org X-Gm-Message-State: AOJu0YxVSSrsh58TIYb4zYQFBDXv8lch95aTrieFHNLpgUqWALX7VciG LECbReaJCvAoHieEvvTUHQ48cOtC1URjGxjV+nIJjxHxoWzetoSRkxwFDtBDW2a0V6OkMyeZwzB tNn/UdAnsuGLSdi0kgJa4WiJNkbGCkuhMsE2k82vTPZS6KOzndCzoTeibGnr/CuKs79U64MtGNp BwOpB2ONWYTGKKnKm9/ZildSeVKGRUGx51+6qJcpGa+rXJlhbM9E2raFbyHnPNy/i3vsaGsHzR+ r7J1WtsH2E+Tc6EzhVrjcQ= X-Gm-Gg: AZuq6aLq25raxoQwcl3sUPokmMYYCWJlszjBNBGq+Yp3VwgBGfeBSM8ZeYBChPD9g7j cN8/mKwXjNB/kkLkSNVRlPyEDkY2/ccxRtHmSUt4DT1KJyDzGlYVrIWI0vGvuCo23ft8vWmfch/ myXO4V2oEPc7vxR7acxjXjoznL/q/utEPr2by4E8oxGt9tnsnAodS10Hm5LBAiu0WgimCibDjoe jZkRTpAOgJbZHNcEs5RvpZ2RYULhVABeEVHqMVDktWBeOBPgFSp6W1D0SgIv1CED11QYSDORWVI vlnDuVqIocHU4sJumER5IFsCSKU4yNP7DML89pX6fB7FLNkgMx2dM6XZjWbW2X5bzw8uzUs9PHn jCiMaYLLcc/0YbZSx+0p/M9ECsMbCpghFDWPx+TKXeJ6H8VNvlnl3O2BQEYebtX9cu4/DrFihol c3o6gxP/DNq7GHLCQPWkblplpTMSmyXrLogo7g8AHMWwjRf5HMPHM= X-Received: by 2002:ad4:4d49:0:b0:895:498e:e9dd with SMTP id 6a1803df08f44-895498eeaf1mr8872986d6.2.1770417716970; Fri, 06 Feb 2026 14:41:56 -0800 (PST) Received: from smtp-us-east1-p01-i01-si01.dlp.protect.broadcom.com (address-144-49-247-103.dlp.protect.broadcom.com. [144.49.247.103]) by smtp-relay.gmail.com with ESMTPS id af79cd13be357-8caf8e6e7b4sm44921185a.6.2026.02.06.14.41.56 for (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Fri, 06 Feb 2026 14:41:56 -0800 (PST) X-Relaying-Domain: broadcom.com X-CFilter-Loop: Reflected Received: by mail-dy1-f197.google.com with SMTP id 5a478bee46e88-2b866e72c00so220433eec.1 for ; Fri, 06 Feb 2026 14:41:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=broadcom.com; s=google; t=1770417716; x=1771022516; darn=vger.kernel.org; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to; bh=MbTioyKnkYFn3YmIZ+Irbz8xYrMm1V4XqCu/uXGzVWU=; b=ABiUBodrPvPflyOdEtZGCauQFNSh7RKURJvWjKiR7WMtjNaJlYvPWR3lL8Dmla6P+2 xWNIBEbE74aNiFCgdEh8YrGrX0ZyRwxj4gAbtfRnL6CXKMtOSzUAKkxBUl5rKXaccJzh oA02awf8OpMbQc6WZxq7r8aIehvNTk5QALzBc= X-Forwarded-Encrypted: i=1; AJvYcCXJ5MhTHJ/poQJ+tvEioUPSI/nPgpzr6C731Wh2g8w/3ZXqSIKJrq1f9pVKIFKMGGXUoXXIKiIO6/D7k0M=@vger.kernel.org X-Received: by 2002:a05:7300:d51a:b0:2b8:31e5:91b with SMTP id 5a478bee46e88-2b856830c4bmr2168975eec.32.1770417715558; Fri, 06 Feb 2026 14:41:55 -0800 (PST) X-Received: by 2002:a05:7300:d51a:b0:2b8:31e5:91b with SMTP id 5a478bee46e88-2b856830c4bmr2168958eec.32.1770417714963; Fri, 06 Feb 2026 14:41:54 -0800 (PST) Received: from [10.66.193.70] ([192.19.161.250]) by smtp.gmail.com with ESMTPSA id 5a478bee46e88-2b855c3c7cbsm2649807eec.17.2026.02.06.14.41.53 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 06 Feb 2026 14:41:54 -0800 (PST) Message-ID: Date: Fri, 6 Feb 2026 14:41:51 -0800 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] x86/vmware: Fix hypercall clobbers To: Linus Torvalds , Josh Poimboeuf Cc: Thomas Gleixner , Thorsten Leemhuis , x86@kernel.org, linux-kernel@vger.kernel.org, Ajay Kaher , bcm-kernel-feedback-list@broadcom.com, Peter Zijlstra , Justin Forbes , Linux kernel regressions list References: <99a9c69a-fc1a-43b7-8d1e-c42d6493b41f@broadcom.com> <73641ce4-9387-48c6-8904-74997f9bb7ac@leemhuis.info> <87jywq18yt.ffs@tglx> Content-Language: en-US From: Alexey Makhalov Autocrypt: addr=alexey.makhalov@broadcom.com; keydata= xsFNBGVo9lkBEACeouRIm6Q3QTvjcnPczfBqgLffURstVJz5nqjnrNR4T+8dwNrZB8PTgOWA QdGV4bIyqtNG7UHQuZ7sVKr2tx0gYJyQ5uZgncEHB5YIuhQ/CyAHrVmO+5/0/xWCLI0g44rF ZJqsYw2JQ2+vayTWbR65rkOiKL8GOVFNZanDg80BRh6qCmCEMXd/tymxvgnvWpHtxMgukexk 4vV9nV4XhxRVYdpLk8mBxsh+AEbHE+nbWgIuJDrmrZDGI2Dha7JFoB0Mi6hbbYd9BdkcHKQ7 6c+S1xOrZL3jX7OIFhb4NNnEOhh8/+BDlyby478p6YsimNa7TgAUbrygGyfVG8usrZy8SvO+ vUbVQwqjcJaCK1xazK12dfuZm2kSMJUrJqa9ng6OMjkE2/WrtnK8ruFNSCdytzbuheT0nYUJ Uwy84cU4p2K/N2C4vYjcn+IT+l1BFr5FViKYruoRLVH6zK/WOoZjA+Fc6tdM5nC1pgSB9c7h XLQqDSzYPzk3nqeHWG1qJ0Hu7pscIrjxyNTIZ5le0TlpblJdoRcL5maDNw22yle8m4D18ERF VrqNoqwW8fObMCHbd6C3m75lzerq1HhrSvLyU4UfprEyAcjOI1C0319SXfYlXDjKXRQyaDZP wxln8uShSitSSnx0AsSAjcUa8Cc7km81+G2WSK3S2wVIAN11awARAQABzS5BbGV4ZXkgTWFr aGFsb3YgPGFsZXhleS5tYWtoYWxvdkBicm9hZGNvbS5jb20+wsGNBBMBCAA3FiEEjLzRtST/ a5u42vOKbM7yHr5SJ3cFAmVo9lwFCQ0oaIACGwMECwkIBwUVCAkKCwUWAgMBAAAKCRBszvIe vlInd0jTD/9bZtjehewLRrW3dRDAbLG/+J5g1K4X5qQPfAo42NrhZQlOTibL7ixwq7NSXynZ V4Iu9jHAW++KXjxJzkg7zjBf9OOvvgCpqZGKYgWNvHHnX4eIVh8Ikp5JtvGPMBcRv7lJA5co kb+RHo9iRrB1dvRIOsP1SlGS85SiNA0yvmgqwbigLDmDRSWtvvt9XPwU1iqF+1OopT3UE10i /z+qE2ogcw2ADveBovq2W4JeQEBvlETwDKOdh8Q3UBHOqrZUrL7YjpUxgmb89FcjdDzUU95I fCB5YxF0hUctxFH5Uujh2F4qk0m2rp7+aOGtxWCJUqkHXjgpOoxyn0FPZiZlDkst84NO5OSI 5ZFPwaFqxUrFF+cFCY2O/UE2gpoK9Lt3gYNK6o2WIAtufuiYVdK6lANMkBgZ+t2fDLIN147a 172zu8XnyJMTo+tVfUjxwqynoR/NSWpVPs0Ck3K0LGjQE0tJ6HZrH0vudXk3YaiqW+D4CtGh I17Pk0h6x8LCdjmWmuDXoc99ezOEFSyWuTHjAYxx3cmgSUyIhdHtimuf0CVLTcFoBErb/5pJ zjb11Cj0HP87FMH57bnD3qyfkBMOB6tztfdt3vkCBaWkxaiTGXNhwr4IiLUoi90yIdXDMcTj /gvnjXgN+31iYgPWgTOdUEQud0DwDwuDwkzx/0x4sF1Dfc7BTQRlaPZcARAAuGkoYKWcrCh8 5RffedM6uBZ4p5Z4+RVj05uq7hlAwhHUpLP/XGbgNzhJP375Lonmnuyg2x7oHxfiwOohuuiA MnhSeEXn2qWZJuHosrYxs9y2zyiE/GTUAcqKiYBFa/96zOaZjHpNuQ5qSHYL64WhqvtmCQYg fL+jes2Z4IXl2R7MrN9OE+G3A3pOAo8TZKUEmlUV85fSmgopIX+hCiSQmRNRtp2jK6hd2+38 YAXc+eRxYgXKaWX5zeBgNrfM7Oxeh/0iWRZPWstTvVH2xMlzywOB3e/fqg+Q3NlPGDrTyHoc L86ZELSLcMTFn+RXw8lX8oVjTcQA0M8sQHB5g0JEWtMsFjnQZkJGCfeh0Odbn/F8nZ6LQQtu +fjc/4n9vRun+PZjdhd3W9ZM9D87W9XJg9txIaYnoUXBLLpHK/OirFfr5cJTUf4svtE3EVXb x6P9vr7zqUbE0f76h1eDPmyMwFAuibIXhNoEoKQtEjLX9aKgKYny3hczRiuQpA+6U4oTNn4S /CEqphLPT53aMH0w4x0CebMPozf24ZE9YphdX8ECclLBlDL1/zx2xKrJNw8v6wdXMSfsybBW 98b5b1eVBk1uc1UMlpDl7AIHyCMTjL9Ha85eoya/Hk9l93aVHgK04hOBY2ED1/ZRpj0M5P5m tNX1JqZunpyvKooT1PrJr4UAEQEAAcLBfAQYAQgAJhYhBIy80bUk/2ubuNrzimzO8h6+Uid3 BQJlaPZeBQkNKGiAAhsMAAoJEGzO8h6+Uid3SDoQAI3XXqsehWKvyAVeGXPxmkk+Suos/nJC xZWjp4U2xbbegBnNWladZoNdlVW/WV+FSFsN5IWztxQTWBMI12A0dx+Ooi9PSIANnlN+gQsA 9WeQ5iDNveEHZyK1GmuqZ3M3YZ1r3T2KyzTnPPZQ1B8gMQ442bOBWe077MqtLaC0J1jHyWHU j6BbUCAyR2/OCV/n1bH4wYIm2lgrOd2WuzoAGvju+j2g7hMRxw/xeHeu8S0czHuEZ0dC6fR1 ZKUOw03+mM/xRzL1be6RVS9AF7R5oDd11RrTOb7k14z0inFqSRrRwzOPKcuMxrApcquar336 3FQuLcJLjBo/SAOh2JatOkkwkw5PZseqdwcAk5+wcCbdYy8J8ttR04iV1FzrdQp8HbVxGNo7 AlDn1qtoHzvJHSQG51tbXWfLIi1ek3tpwJWj08+Zo+M47X6B65g7wdrwCiiFfclhXhI1eJNy fqqZgi3rxgu4sc5lmR846emZ/Tx85/nizqWCv7xUBxQwmhRPZRW+37vS2OLpyrTtBj3/tEM9 m9GMmTZqaJFeK7WCpprJV4jNHpWZuNAsQrdK1MrceIxb0/6wYe0xK79lScxms+zs9pGTrO4U 5RoS4gXK65ECcBH8/mumV6oBmLrNxKUrzTczdo9PnkmRyZcAa6AndbjmQDznwxvTZu2LjMPC EuY0 In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-DetectorID-Processed: b00c1d49-9d2e-4205-b15f-d015386d3d5e 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 > *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 . 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