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...
Cheers,
M.
--
Jazz is not dead. It just smells funny...
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
