public inbox for kvm@vger.kernel.org
 help / color / mirror / Atom feed
From: Michael Ellerman <mpe@ellerman.id.au>
To: Paolo Bonzini <pbonzini@redhat.com>, torvalds@linux-foundation.org
Cc: linux-kernel@vger.kernel.org, rkrcmar@redhat.com,
	kvm@vger.kernel.org,
	Christian Borntraeger <borntraeger@de.ibm.com>,
	Christoffer Dall <christoffer.dall@linaro.org>,
	Dan Williams <dan.j.williams@intel.com>,
	Marc Zyngier <marc.zyngier@arm.com>,
	Paul Mackerras <paulus@ozlabs.org>
Subject: Re: [GIT PULL] KVM changes for 4.8 merge window
Date: Wed, 03 Aug 2016 16:46:10 +1000	[thread overview]
Message-ID: <87d1lql58t.fsf@concordia.ellerman.id.au> (raw)
In-Reply-To: <12aabe49-09c5-35db-e15c-bf2b75bd3f67@redhat.com>

Paolo Bonzini <pbonzini@redhat.com> writes:

> On 03/08/2016 05:21, Michael Ellerman wrote:
>> Paolo Bonzini <pbonzini@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.

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

  reply	other threads:[~2016-08-03  6:46 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-08-02 12:37 [GIT PULL] KVM changes for 4.8 merge window Paolo Bonzini
2016-08-02 18:02 ` Christian Borntraeger
2016-08-02 18:42   ` Linus Torvalds
2016-08-02 20:17     ` Linus Torvalds
2016-08-02 20:49       ` Christian Borntraeger
2016-08-02 21:36       ` Martin Schwidefsky
2016-08-02 21:46         ` Linus Torvalds
2016-08-02 18:55   ` Paolo Bonzini
2016-08-03  3:21 ` Michael Ellerman
2016-08-03  6:26   ` Paolo Bonzini
2016-08-03  6:46     ` Michael Ellerman [this message]
2016-08-03 11:00       ` Paolo Bonzini

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87d1lql58t.fsf@concordia.ellerman.id.au \
    --to=mpe@ellerman.id.au \
    --cc=borntraeger@de.ibm.com \
    --cc=christoffer.dall@linaro.org \
    --cc=dan.j.williams@intel.com \
    --cc=kvm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=marc.zyngier@arm.com \
    --cc=paulus@ozlabs.org \
    --cc=pbonzini@redhat.com \
    --cc=rkrcmar@redhat.com \
    --cc=torvalds@linux-foundation.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox