[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <ZWobgUtVj5xmdJX7@google.com>
Date: Fri, 1 Dec 2023 09:44:33 -0800
From: Sean Christopherson <seanjc@...gle.com>
To: Paul Durrant <pdurrant@...zon.co.uk>
Cc: Paul Durrant <paul@....org>, David Woodhouse <dwmw2@...radead.org>,
Paolo Bonzini <pbonzini@...hat.com>,
Thomas Gleixner <tglx@...utronix.de>,
Ingo Molnar <mingo@...hat.com>, Borislav Petkov <bp@...en8.de>,
Dave Hansen <dave.hansen@...ux.intel.com>,
"x86@...nel.org" <x86@...nel.org>,
"H. Peter Anvin" <hpa@...or.com>,
"kvm@...r.kernel.org" <kvm@...r.kernel.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 0/2] KVM: xen: update shared_info when long_mode is set
On Fri, Dec 01, 2023, Paul Durrant wrote:
> > On Fri, Dec 01, 2023, Paul Durrant wrote:
> > > From: Paul Durrant <pdurrant@...zon.com>
> > >
> > > This series is based on my v9 of my "update shared_info and vcpu_info
> > > handling" series [1] and fixes an issue that was latent before the
> > > "allow shared_info to be mapped by fixed HVA" patch of that series allowed
> > > a VMM to set up shared_info before the VM booted and then leave it alone.
> >
> > Uh, what? If this is fixing an existing bug then it really shouldn't take a
> > dependency on a rather large and non-trivial series. If the bug can only manifest
> > as a result of said series, then the fix absolutely belongs in that series.
> >
>
> There's been radio silence on that series for a while so I was unsure of the status.
v9 was posted the day before Thanksgiving, the week after plumbers, and a few
weeks after the merge window closed. And it's an invasive series to some of KVM's
gnarliest code, i.e. it's not something that can be reviewed in passing. We're
also entering both the holiday season and the end of the year when people get
sucked into annual reviews and whatnot.
I totally understand that it can be frustrating when upstream moves at a glacial
pace, but deviating from the established best practices is never going to speed
things up, and is almost always going to do the exact oppositie.
Powered by blists - more mailing lists