lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <Z34xp0ret-5Zcgo9@liuwe-devbox-debian-v2>
Date: Wed, 8 Jan 2025 08:04:55 +0000
From: Wei Liu <wei.liu@...nel.org>
To: Roman Kisel <romank@...ux.microsoft.com>
Cc: Stanislav Kinsburskii <skinsburskii@...ux.microsoft.com>, hpa@...or.com,
	kys@...rosoft.com, bp@...en8.de, dave.hansen@...ux.intel.com,
	decui@...rosoft.com, eahariha@...ux.microsoft.com,
	haiyangz@...rosoft.com, mingo@...hat.com, mhklinux@...look.com,
	nunodasneves@...ux.microsoft.com, tglx@...utronix.de,
	tiala@...rosoft.com, wei.liu@...nel.org,
	linux-hyperv@...r.kernel.org, linux-kernel@...r.kernel.org,
	x86@...nel.org, apais@...rosoft.com, benhill@...rosoft.com,
	ssengar@...rosoft.com, sunilmut@...rosoft.com, vdso@...bites.dev
Subject: Re: [PATCH v5 3/5] hyperv: Enable the hypercall output page for the
 VTL mode

On Tue, Jan 07, 2025 at 03:11:15PM -0800, Roman Kisel wrote:
> 
> 
> On 1/7/2025 11:18 AM, Stanislav Kinsburskii wrote:
> > On Mon, Jan 06, 2025 at 01:07:25PM -0800, Roman Kisel wrote:
> > 
> 
> [...]
> 
> > My point is that the proposed fix looks more like an Underhill-tailored
> > bandage and doesn't take the needs of other stake holders into
> > consideration.
> The patch takes as much into consideration as present in the hyperv-next
> tree. Working on the open-source project seems to be harder otherwise.
> A bandage, or not, that's a matter of opinion. There's a been a break,
> here's the bandage.
> 
> > 
> > What is the urgency in merging of this particular change?
> 
> The get_vtl function is broken thus blocking any further work on
> upstreaming VTL mode patches, ARM64 and more. That's not an urgent
> urgency where customers are in pain, more like the urgency of needing
> to take the trash out, and until that happens, continuing inhaling the
> fumes.
> 
> The urgency of unblocking is to continue work on proposing VTL mode
> patches not to carry lots of out-of-tree code in the fork.
> 
> There might be a future where the Hyper-V code offers an API surface
> covering needs of consumers like dom0 and VTLs whereby they maybe can
> be built as an out-of-tree modules so the opinions wouldn't clash as
> much.
> 
> Avoiding using the output hypercall page leads to something like[1]
> and it looks quite complicated although that's the bare bones, lots
> of notes.
> 
> [1]
> 
> /*
>  * Fast extended hypercall with 20 bytes of input and 16 bytes of
>  * output for getting a VP register.
>  *
>  * NOTES:
>  *  1. The function is __init only atm, so the XMM context isn't
>  *     used by the user mode.
>  *  2. X86_64 only.
>  *  3. Fast extended hypercalls may use XMM0..XMM6, and XMM is
>  *     architerctural on X86_64 yet the support should be enabled
>  *     in the CR's. Here, need RDX, R8 and XMM0 for input and RDX,
>  *     R8 for output
>  *  4. No provisions for TDX and SEV-SNP for the sake of simplicity
>  *     (the hypervisor cannot see the guest registers in the
>  *     confidential VM), would need to fallback.

I am not worried about this point. There are architectural defined ways
to handle this.

>  *  5. The robust implementation would need to check if fast extended
>  *     hypercalls are available by checking the synthehtic CPUID leaves.
>  *     A separate leaf indicates fast output support.
>  *     It _almost_ certainly has to be, unless somehow disabled, hard
>  *     to see why that would be needed.
>  */

The rest I agree. Not worth the effort just to add that support here for
a single user.

I've been thinking about adding the extended hypercall support for a
while, but I'm not sure if it's worth the effort overall.

An aspiring developer who's interested in this area is building a
prototype to see if extended fast hypercall can give a boost to some of
the frequent hypercalls.

In any case, I think this patch is fine.

Thanks,
Wei.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ