On 05/06/13 13:57, Gleb Natapov wrote: > On Wed, Jun 05, 2013 at 10:31:46AM +0100, Catalin Marinas wrote: >> On Wed, Jun 05, 2013 at 07:01:05AM +0100, Gleb Natapov wrote: >>> On Tue, Jun 04, 2013 at 10:57:32PM -0700, Christoffer Dall wrote: >>>> On 4 June 2013 09:37, Gleb Natapov <gleb@xxxxxxxxxx> wrote: >>>>> On Tue, Jun 04, 2013 at 05:51:41PM +0200, Paolo Bonzini wrote: >>>>>> Il 04/06/2013 17:43, Christoffer Dall ha scritto: >>>>>>> Hi Paolo, >>>>>>> >>>>>>> I don't think this is an issue. Gleb and Marcelo for example pulled >>>>>>> RMK's stable tree for my KVM/ARM updates for the 3.10 merge window and >>>>>>> that wasn't an issue. If Linus pulls the kvm/next tree first the >>>>>>> diffstat should be similar and everything clean enough, no? >>>>>>> >>>>>>> Catalin has previously expressed his wish to upstream the kvm/arm64 >>>>>>> patches directly through him given the churn in a completely new >>>>>>> architecture and he wants to make sure that everything looks right. >>>>>>> >>>>>>> It's a pretty clean implementation with quite few dependencies and >>>>>>> merging as a working series should be a priority instead of the >>>>>>> Kconfig hack, imho. >>>>>> >>>>>> Ok, let's see what Gleb says. >>>>>> >>>>> I have no objection to merge arm64 kvm trough Catalin if it mean less >>>>> churn for everyone. That's what we did with arm and mips. Arm64 kvm >>>>> has a dependency on kvm.git next though, so how Catalin make sure that >>>>> everything looks right? Will he merge kvm.git/next to arm64 tree? >>>>> >>>> Yes, that was the idea. Everything in kvm/next is considered stable, right? >>>> >>> Right. Catalin should wait for kvm.git to be pulled by Linus next merge >>> windows before sending his pull request then. >> >> I think it's better if I push the bulk of the arm64 KVM branch but >> without Kconfig patch enabling it. This branch would be based on >> mainline rather than kvm/next. Once your code goes in mainline, I'll >> just push the Kconfig entry (for bisection reasons, it could be after >> -rc1). This would keep the pull-request diffstat cleaner. >> > If there will be no non trivial conflicts between your tree and kvm/next > it should be OK too. In order to make sure no userspace ABI breakage occur during the merge, can you please make sure that the following values are reserved: - Capability KVM_CAP_ARM_EL1_32BIT, 93 - ONE_REG architecture KVM_REG_ARM64, 0x6000000000000000ULL So far, nothing clashes with it in kvm/next, but I'd like to be 100% sure... Thanks, 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 majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
