Planning the merge of KVM/arm64

[Marc Zyngier]

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 at redhat.com> 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...