On Tue, 16 Jan 2018, Paolo Bonzini wrote: > On 16/01/2018 01:55, Ingo Molnar wrote: > > > > * Paolo Bonzini <pbonzini@xxxxxxxxxx> 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 -- To unsubscribe from this list: send the line "unsubscribe linux-next" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
