On 03/08/2016 05:21, Michael Ellerman wrote: > Paolo Bonzini <pbonz...@redhat.com> 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. Considering the h in "hmi" is for hypervisor, 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. 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. Paolo
