On 11 November 2013 10:26, Marc Zyngier <marc.zyngier@xxxxxxx> 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 -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
