Paolo Bonzini <pbonzini@xxxxxxxxxx> writes: > On 03/08/2016 05:21, Michael Ellerman wrote: >> Paolo Bonzini <pbonzini@xxxxxxxxxx> writes: >> ... >>> - arch/powerpc: what a mess. For the idle_book3s.S conflict, the KVM >>> tree is the right one; everything else is trivial. In this case I am >>> not quite sure what went wrong. The commit that is causing the mess >>> (fd7bacbca47a, "KVM: PPC: Book3S HV: Fix TB corruption in guest exit >>> path on HMI interrupt", 2016-05-15) touches both arch/powerpc/kernel/ >>> and arch/powerpc/kvm/. It's large, but at 396 insertions/5 deletions >>> I guessed that it wasn't really possible to split it and that the 5 >>> deletions wouldn't conflict. That wasn't the case. >> >> In fact I think the problem is that this patch shouldn't have gone via the KVM >> tree at all. >> >> If you look at the diffstat, it doesn't touch anything in generic KVM, but lots >> of arch code: > > The KVM tree merges all arch/*/kvm code from submaintainers. Only Radim > and I send patches directly to Linus. Sure. But that's really my point. Just because a patch touches arch/*/kvm, doesn't mean it must go via the KVM tree. If the only arch code it touches is arch/*/kvm, then it should trivially go via the KVM tree. But if it touches other arch code then it's quite likely it will end up conflicting with the arch tree, in which case it it's less likely to cause problems if it goes into the arch tree, possibly in a topic branch. > Considering the h in "hmi" is for hypervisor, Well hypervisor != KVM. Though in this case hmi.c was pretty safe because it was new code. But if I'd received a powerpc patch to hmi.c I wouldn't have thought to check if it conflicted with the KVM tree. > actual non-virt code in that patch was this: > > arch/powerpc/include/asm/paca.h | 6 +++ > arch/powerpc/kernel/Makefile | 2 +- > arch/powerpc/kernel/exceptions-64s.S | 4 +- > arch/powerpc/kernel/idle_power7.S | 5 ++- > arch/powerpc/kernel/traps.c | 5 +++ > > So the changes are pretty small, yet apart from paca.h every file ended > up having a conflict with the PPC tree. So I think it's just very bad > luck in this case. I guess. Makefile changes often conflict, though they're usually trivial, and I'd guess exceptions-64s.S is patched in some way in most releases. But if there are changes outside arch/*/kvm in the KVM tree then it's just luck if they don't conflict. > Having this patch in a topic branch merged by both PPC and KVM > maintainers would have still been a good idea, because I guess Paul > knew of Ben's idle_power7.S cleanup. I'm not sure who knew what when. Paul was travelling for some of the merge window, and I was sick for some of it, so mistakes were made :) cheers -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
