Re: [PATCH 2/3] arm/arm64: KVM: MMIO support for BE guest

Christoffer Dall
2013-11-11T18:41:11Z

On 11 November 2013 10:26, Marc Zyngier <marc.zyngier@arm.com> wrote:
> Paolo,
>
> On 11/11/13 17:56, Paolo Bonzini wrote:
>> 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 is no QEMU patch so far, as Peter (CC-ed) doesn't want to support
> such a configuration and prefers to stick to a setups for which an
> actual platform exist in QEMU.
>
> This doesn't really change the ABI:
> - Configurations with more than 4 CPUs were rejected until now (KVM only
> dealt with a single cluster), and are now accepted
> - CPUs 4 to 7 are part of a second cluster, which is reflected in the
> MPIDR register, just like on HW.
> - The kvmtool patch only deals with DT generation, which was buggy and
> didn't deal properly with multiple clusters.
>
> So anything that was working before still is, and things that were
> wrongly advertised as working are now fixed. All in all, this patch
> series is more a set of bug-fixes than anything else.
>
>>>>> 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.
>
> Mostly because arm64 was developed and merged before any kind of useful
> documentation was publicly available. As I've written most of the code,
> it was only logical that I'd assume responsibility for it.
>
> Christoffer and I are actually working quite well together, and I don't
> think there is much to improve, short of sharing a common git tree. And
> to be perfectly clear, I wouldn't mind if we were written down as
> co-maintainers for both ports...
>
I completely agree, I feel the collaboration works well too, and we
can change the git workflow a bit and list us both as co-maintainers
if required. It seems this is how it effectively works today, I don't
merge anything unless Marc gives his ack and I believe it's the other
way around too.

-Christoffer