[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <alpine.DEB.2.20.1801161606510.1823@nanos>
Date: Tue, 16 Jan 2018 16:08:20 +0100 (CET)
From: Thomas Gleixner <tglx@...utronix.de>
To: Paolo Bonzini <pbonzini@...hat.com>
cc: Ingo Molnar <mingo@...nel.org>,
Stephen Rothwell <sfr@...b.auug.org.au>,
Radim Krčmář <rkrcmar@...hat.com>,
KVM <kvm@...r.kernel.org>, Ingo Molnar <mingo@...e.hu>,
"H. Peter Anvin" <hpa@...or.com>,
Peter Zijlstra <peterz@...radead.org>,
Linux-Next Mailing List <linux-next@...r.kernel.org>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
David Woodhouse <dwmw@...zon.co.uk>,
Tom Lendacky <thomas.lendacky@....com>,
Brijesh Singh <brijesh.singh@....com>,
Borislav Petkov <bp@...en8.de>
Subject: Re: linux-next: manual merge of the kvm tree with Linus' and the
tip trees
On Tue, 16 Jan 2018, Paolo Bonzini wrote:
> On 16/01/2018 01:55, Ingo Molnar wrote:
> >
> > * Paolo Bonzini <pbonzini@...hat.com> wrote:
> >
> >> On 15/01/2018 19:36, Thomas Gleixner wrote:
> >>>> Can KVM folks please stop doing random changes to the cpufeatures code
> >>>> without talking to x86 maintainers and Borislav?
> >>>>
> >>>> This wants to go through TIP or at least reviewed and acked.
> >>> In fact it needs to go through TIP. We spent a lot of effort to make the
> >>> backporting of all this mess simple and this is just shooting a hole in it.
> >>
> >> I do understand why you want this to go through TIP, but I'm not sure
> >> why a change to Processor Tracing is related to PTI or retpolines. I'm
> >> also not sure why it is a problem for backportability, since we always
> >> try to send pull requests after TIP. Is it because 7*32+15 will be free
> >> in 4.16 but not earlier?
> >
> > It is because certain central x86 changes (such as changes to processor flags)
> > are kept on a v4.14 base to keep the PTI backporting efforts manageable.
> >
> > Please revert (or rebase) this change from the KVM tree, and submit it separately,
> > as it should have been done to begin with. Please also follow this process in the
> > future: all x86 changes outside arch/x86/kvm/ need an explicit ack from an x86
> > maintainer.
>
> I've always done it like that until
> https://marc.info/?l=kvm&m=149335647027790 got no response for three
> months, then I thought you didn't care.
Well, I certainly cared, but was kaisered enough to not look.
> We will drop Intel PT support and delay it to 4.17. Luwei, since your
> patches have issues with incorrect use of the MSR bitmap, this is
> probably a good thing anyway (better bisectability). Please repost your
> patches at the end of the merge window, then we will wait for an ack
> from Thomas/Ingo/Peter.
Can we get all cpu feature bit specific patches now please so we can move
them through TIP?
Thanks,
tglx
Powered by blists - more mailing lists