On Fri, Oct 03, 2025 at 09:31:41AM -0700, Stanislav Kinsburskii wrote: > 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?) > > > > I'm not sure I understand what "shipped version" of hypervisor actually > is. > As of today, the hypervisor is close source and the only product where > it's used is Azure. In Azure, the older versions of hypervisor are > replaced with newer on regular basis. > > > 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. > > > > Given that these changes are expected to land to a newly released > kernel, it will take time until this kernel gets to production. At that > moment it's highly likley that the older versions of hypervisor you are > trying to support here will be gone for good.
No. This is not 100% certain. The schedule is outside of our control. Who knows if there is a specialized Azure cluster that is not updated for some reason. Interested parties have already started experimenting with this new setup. I just point them to the upstream tree whenever I can. > Even if they won't be gone, they will be obsoleted and intended to be > replaced which effecitively makes this support of older versions a > dead weight, which - if needed to be caried - is cleaner to keep in house > and drop when apporiate than keeping in the upstream code base. > While the maintenance burden argument generally applies, the burden in this case is not big. It is totally fine to have the code. Wei > Thanks, > Stas > > > Nuno > > > > > Thanks, > > > Stanislav > > > > > >
