linux-kernel - Re: [PATCH v4 0/5] mshv: Fixes for stats and vp state page mappings

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] [day] [month] [year] [list]

Message-ID: <aNxkZtyxuYQ0Gjw7@liuwe-devbox-ubuntu-v2.lamzopl0uupeniq2etz1fddiyg.xx.internal.cloudapp.net>
Date: Tue, 30 Sep 2025 23:14:46 +0000
From: Wei Liu <wei.liu@...nel.org>
To: Nuno Das Neves <nunodasneves@...ux.microsoft.com>
Cc: Stanislav Kinsburskii <skinsburskii@...ux.microsoft.com>,
	linux-hyperv@...r.kernel.org, linux-kernel@...r.kernel.org,
	prapal@...ux.microsoft.com, easwar.hariharan@...ux.microsoft.com,
	tiala@...rosoft.com, anirudh@...rudhrb.com,
	paekkaladevi@...ux.microsoft.com, kys@...rosoft.com,
	haiyangz@...rosoft.com, wei.liu@...nel.org, decui@...rosoft.com
Subject: Re: [PATCH v4 0/5] mshv: Fixes for stats and vp state page mappings

On Mon, Sep 29, 2025 at 11:19:51AM -0700, Nuno Das Neves wrote:
> On 9/26/2025 4:12 PM, Stanislav Kinsburskii wrote:
> > On Fri, Sep 26, 2025 at 09:23:10AM -0700, Nuno Das Neves wrote:
> >> There are some differences in how L1VH partitions must map stats and vp
> >> state pages, some of which are due to differences across hypervisor
> >> versions. Detect and handle these cases.
> >>
> > 
> > I'm not sure that support for older and actully broken versions on
> > hypervisor need to be usptreamed, as these versions will go away sooner
> > or later and this support will become dead weight.
> > 
> As far as I know, these changes are relevant for shipped versions of the
> hypervisor - they are not 'broken' except in some very specific cases
> (live migration on L1VH, I think?)
> 

Right, they are not broken, just have more limitations.

> The hypervisor team added a feature bit for these changes so that both old
> and new versions of these APIs can be supported.
> 
> > I think we should upstrem only the changes needed for the new versiong
> > of hypervisors instead and carry legacy support out of tree until it
> > becomes obsoleted.
> > 
> Which version do you suggest to be the cutoff?
> 
> I'd prefer to support as many versions of the hypervisor as we can, as
> long as they are at all relevant. We can remove the support later.
> Removing prematurely just creates friction. Inevitably some users will
> find themselves running on an older hypervisor and then it just fails
> with a cryptic error. This includes myself, since I test L1VH on Azure
> which typically has older hypervisor versions.

This. It takes a long time to saturate the fleet with a new hypervisor.
Realistically I am looking at 2+ years before we can drop the
compatibility code, if ever.

Another reason to upstream the compatibility code is because partners
will want to pick up our code, so hiding this code from them makes both
our and their life harder.

Wei

> 
> Nuno