public inbox for kvm@vger.kernel.org
 help / color / mirror / Atom feed
From: Paolo Bonzini <pbonzini@redhat.com>
To: Christoffer Dall <christoffer.dall@linaro.org>
Cc: Marc Zyngier <marc.zyngier@arm.com>,
	Gleb Natapov <gleb@redhat.com>,
	"kvm@vger.kernel.org" <kvm@vger.kernel.org>,
	"kvmarm@lists.cs.columbia.edu" <kvmarm@lists.cs.columbia.edu>
Subject: Re: [PATCH 2/3] arm/arm64: KVM: MMIO support for BE guest
Date: Mon, 11 Nov 2013 18:56:12 +0100	[thread overview]
Message-ID: <52811A3C.2050101@redhat.com> (raw)
In-Reply-To: <CAMJs5B_9m-GTNNHr2z2iVkcDO=kSOr8S9Wi9_iNf7bNEDNgTEQ@mail.gmail.com>

Il 11/11/2013 16:49, Christoffer Dall ha scritto:
> I don't think it would have made much sense - that patch was part of a
> series that was touching mainly arch/arm/kvm/* and therefore I
> included it in my pull.  It would have been strange to have a
> kvm-arm-next tree that included 75% of the functionality because Marc
> happens to have another patch that touches arch/arm and arch/arm64 and
> have two untestable trees until the merge window...

Yes, I found the original series now at
http://thread.gmane.org/gmane.linux.ports.arm.kernel/274722/.

BTW, why did the arm/arm64 patch move from patch 1 in Marc's post to
patch 4 here?  Also, the description says "this also requires a patch to
kvmtool so the generated DT matches the expectations of the guest
(posted separately)".  Does this apply to QEMU as well?  If so, can you
please point me to the QEMU patch?  How does this patch affect guest
ABI, and is guest ABI not yet considered stable for KVM ARM?

Sorry for the question storm. :)

>>> There would still be the case where I carry those arm/arm64
>>> patches but the arm64 changes conflict with those in Marc's tree, no?
>>
>> Yes, that can still happen.  Conflicts are not bad, only inconsistencies
>> are.
>
> Not sure what you mean and where we could be more consistent to make
> life easier for you.  You say it should always come from the same
> person, but not necessary always from the same person?
> 
> Note: I have no problem giving my ack to patches or follow any
> procedure that makes it easier, but I thought these pull requests were
> quite clean (albeit a bit late).

The pull requests were clean and my life wasn't complicated much...  On
the other hand I'm trying to understand if there's something that can be
improved because the conflict surprised me.  Right now, in fact, it's
not even entirely clear to me why ARM and ARM64 have separate maintainers.

Paolo

  reply	other threads:[~2013-11-11 17:56 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-11-08 10:07 [GIT PULL] KVM/arm64 fixes for 3.13 Marc Zyngier
2013-11-08 10:07 ` [PATCH 1/3] arm64: KVM: Yield CPU when vcpu executes a WFE Marc Zyngier
2013-11-08 10:07 ` [PATCH 2/3] arm/arm64: KVM: MMIO support for BE guest Marc Zyngier
2013-11-11 11:04   ` Paolo Bonzini
2013-11-11 14:56     ` Christoffer Dall
2013-11-11 15:10       ` Paolo Bonzini
2013-11-11 15:49         ` Christoffer Dall
2013-11-11 17:56           ` Paolo Bonzini [this message]
2013-11-11 18:03             ` Peter Maydell
2013-11-11 18:05               ` Paolo Bonzini
2013-11-11 18:26             ` Marc Zyngier
2013-11-11 18:41               ` Christoffer Dall
2013-11-11 18:41               ` Paolo Bonzini
2013-11-12  9:41                 ` Andrew Jones
2013-11-12 10:03                   ` Marc Zyngier
2013-11-12 10:07                     ` Paolo Bonzini
2013-11-12 16:30                       ` Christoffer Dall
2013-11-11 18:39             ` Christoffer Dall
2013-11-08 10:07 ` [PATCH 3/3] arm/arm64: KVM: PSCI: propagate caller endianness to the incoming vcpu Marc Zyngier

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=52811A3C.2050101@redhat.com \
    --to=pbonzini@redhat.com \
    --cc=christoffer.dall@linaro.org \
    --cc=gleb@redhat.com \
    --cc=kvm@vger.kernel.org \
    --cc=kvmarm@lists.cs.columbia.edu \
    --cc=marc.zyngier@arm.com \
    /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