Planning the merge of KVM/arm64

Planning the merge of KVM/arm64

[Marc Zyngier]

Guys,

The KVM/arm64 code is now, as it seems, in good enough shape to be
merged. I've so far addressed all the comments, and it doesn't seem any
worse then what is queued for its 32bit counterpart.

For reference, it is sitting there:
git://git.kernel.org/pub/scm/linux/kernel/git/maz/arm-platforms.git
kvm-arm64/kvm

What is not defined yet is the merge path:
- It is touching some of the arm64 core code, so it would be better if
it was merged through the arm64 tree
- It is depending on some of the patches in the core KVM queue (the
vgic/timer move to virt/kvm/arm/)
- It is also depending on some of the patches that are in the KVM/ARM
queue (parametrized timer interrupt, some MMU/MMIO fixes)

So I can see two possibilities:
- Either I can rely on a stable branch from both KVM and KVM/ARM trees
on which I can base my tree for Catalin/Will to pull,
- Or I ask Catalin to only pull the arm64 part *minus the Kconfig*, and
only merge this last bit when the dependencies are satisfied in Linus' tree.

What do you guys think?

Thanks,

	M.
-- 
Jazz is not dead. It just smells funny...

Planning the merge of KVM/arm64

[Anup Patel]

Hi Marc,

On Tue, Jun 4, 2013 at 5:59 PM, Marc Zyngier <marc.zyngier@arm.com> wrote:
> Guys,
>
> The KVM/arm64 code is now, as it seems, in good enough shape to be
> merged. I've so far addressed all the comments, and it doesn't seem any
> worse then what is queued for its 32bit counterpart.
>
> For reference, it is sitting there:
> git://git.kernel.org/pub/scm/linux/kernel/git/maz/arm-platforms.git
> kvm-arm64/kvm
>
> What is not defined yet is the merge path:
> - It is touching some of the arm64 core code, so it would be better if
> it was merged through the arm64 tree
> - It is depending on some of the patches in the core KVM queue (the
> vgic/timer move to virt/kvm/arm/)
> - It is also depending on some of the patches that are in the KVM/ARM
> queue (parametrized timer interrupt, some MMU/MMIO fixes)
>
> So I can see two possibilities:
> - Either I can rely on a stable branch from both KVM and KVM/ARM trees
> on which I can base my tree for Catalin/Will to pull,
> - Or I ask Catalin to only pull the arm64 part *minus the Kconfig*, and
> only merge this last bit when the dependencies are satisfied in Linus' tree.
>
> What do you guys think?

I had quick look at your kvm-arm64/kvm branch. I agree with the approach
of going through arm64 tree.

FYI, latest tested branch on APM ARMv8 board is kvm-arm64/kvm-3.10-rc3
branch.

>From my side, +1 for the second option that is "pull the arm64 part *minus
the Kconfig*, and ..."

>
> Thanks,
>
>         M.
> --
> Jazz is not dead. It just smells funny...
>
>
> _______________________________________________
> kvmarm mailing list
> kvmarm at lists.cs.columbia.edu
> https://lists.cs.columbia.edu/cucslists/listinfo/kvmarm

Regards,
Anup

Planning the merge of KVM/arm64

[Marc Zyngier]

On 04/06/13 14:13, Anup Patel wrote:

Hi Anup,

> On Tue, Jun 4, 2013 at 5:59 PM, Marc Zyngier <marc.zyngier@arm.com> wrote:
>> Guys,
>>
>> The KVM/arm64 code is now, as it seems, in good enough shape to be
>> merged. I've so far addressed all the comments, and it doesn't seem any
>> worse then what is queued for its 32bit counterpart.
>>
>> For reference, it is sitting there:
>> git://git.kernel.org/pub/scm/linux/kernel/git/maz/arm-platforms.git
>> kvm-arm64/kvm
>>
>> What is not defined yet is the merge path:
>> - It is touching some of the arm64 core code, so it would be better if
>> it was merged through the arm64 tree
>> - It is depending on some of the patches in the core KVM queue (the
>> vgic/timer move to virt/kvm/arm/)
>> - It is also depending on some of the patches that are in the KVM/ARM
>> queue (parametrized timer interrupt, some MMU/MMIO fixes)
>>
>> So I can see two possibilities:
>> - Either I can rely on a stable branch from both KVM and KVM/ARM trees
>> on which I can base my tree for Catalin/Will to pull,
>> - Or I ask Catalin to only pull the arm64 part *minus the Kconfig*, and
>> only merge this last bit when the dependencies are satisfied in Linus' tree.
>>
>> What do you guys think?
> 
> I had quick look at your kvm-arm64/kvm branch. I agree with the approach
> of going through arm64 tree.
> 
> FYI, latest tested branch on APM ARMv8 board is kvm-arm64/kvm-3.10-rc3
> branch.

This is the exact same code, just a slightly different patch split to
implement the separate Kconfig option.

Thanks for testing,

	M.
-- 
Jazz is not dead. It just smells funny...

Planning the merge of KVM/arm64

[Catalin Marinas]

On Tue, Jun 04, 2013 at 02:13:52PM +0100, Anup Patel wrote:
> Hi Marc,
> 
> On Tue, Jun 4, 2013 at 5:59 PM, Marc Zyngier <marc.zyngier@arm.com> wrote:
> > Guys,
> >
> > The KVM/arm64 code is now, as it seems, in good enough shape to be
> > merged. I've so far addressed all the comments, and it doesn't seem any
> > worse then what is queued for its 32bit counterpart.
> >
> > For reference, it is sitting there:
> > git://git.kernel.org/pub/scm/linux/kernel/git/maz/arm-platforms.git
> > kvm-arm64/kvm
> >
> > What is not defined yet is the merge path:
> > - It is touching some of the arm64 core code, so it would be better if
> > it was merged through the arm64 tree
> > - It is depending on some of the patches in the core KVM queue (the
> > vgic/timer move to virt/kvm/arm/)
> > - It is also depending on some of the patches that are in the KVM/ARM
> > queue (parametrized timer interrupt, some MMU/MMIO fixes)
> >
> > So I can see two possibilities:
> > - Either I can rely on a stable branch from both KVM and KVM/ARM trees
> > on which I can base my tree for Catalin/Will to pull,
> > - Or I ask Catalin to only pull the arm64 part *minus the Kconfig*, and
> > only merge this last bit when the dependencies are satisfied in Linus' tree.
> >
> > What do you guys think?
> 
> I had quick look at your kvm-arm64/kvm branch. I agree with the approach
> of going through arm64 tree.
> 
> FYI, latest tested branch on APM ARMv8 board is kvm-arm64/kvm-3.10-rc3
> branch.
> 
> From my side, +1 for the second option that is "pull the arm64 part *minus
> the Kconfig*, and ..."

+1 as well for the second option.

-- 
Catalin

Planning the merge of KVM/arm64

[Christoffer Dall]

On 4 June 2013 05:29, Marc Zyngier <marc.zyngier@arm.com> wrote:
> Guys,
>
> The KVM/arm64 code is now, as it seems, in good enough shape to be
> merged. I've so far addressed all the comments, and it doesn't seem any
> worse then what is queued for its 32bit counterpart.
>

huh?

> For reference, it is sitting there:
> git://git.kernel.org/pub/scm/linux/kernel/git/maz/arm-platforms.git
> kvm-arm64/kvm
>
> What is not defined yet is the merge path:
> - It is touching some of the arm64 core code, so it would be better if
> it was merged through the arm64 tree
> - It is depending on some of the patches in the core KVM queue (the
> vgic/timer move to virt/kvm/arm/)
> - It is also depending on some of the patches that are in the KVM/ARM
> queue (parametrized timer interrupt, some MMU/MMIO fixes)
>
> So I can see two possibilities:
> - Either I can rely on a stable branch from both KVM and KVM/ARM trees
> on which I can base my tree for Catalin/Will to pull,
> - Or I ask Catalin to only pull the arm64 part *minus the Kconfig*, and
> only merge this last bit when the dependencies are satisfied in Linus' tree.
>
> What do you guys think?
>
I would think you would prefer option (1) to get the code in cleaner.
Both the KVM/next tree is stable and I can provide you with a stable
KVM/ARM tree. But I really don't feel strongly about this.

-Christoffer

Planning the merge of KVM/arm64

[Marc Zyngier]

On 04/06/13 15:50, Christoffer Dall wrote:
> On 4 June 2013 05:29, Marc Zyngier <marc.zyngier@arm.com> wrote:
>> Guys,
>>
>> The KVM/arm64 code is now, as it seems, in good enough shape to be
>> merged. I've so far addressed all the comments, and it doesn't seem any
>> worse then what is queued for its 32bit counterpart.
>>
> 
> huh?

That was supposed to be a joke. Obviously, my sense of humour has failed
to impress you here. I'll improve on that in another version of the same
email... ;-)

>> For reference, it is sitting there:
>> git://git.kernel.org/pub/scm/linux/kernel/git/maz/arm-platforms.git
>> kvm-arm64/kvm
>>
>> What is not defined yet is the merge path:
>> - It is touching some of the arm64 core code, so it would be better if
>> it was merged through the arm64 tree
>> - It is depending on some of the patches in the core KVM queue (the
>> vgic/timer move to virt/kvm/arm/)
>> - It is also depending on some of the patches that are in the KVM/ARM
>> queue (parametrized timer interrupt, some MMU/MMIO fixes)
>>
>> So I can see two possibilities:
>> - Either I can rely on a stable branch from both KVM and KVM/ARM trees
>> on which I can base my tree for Catalin/Will to pull,
>> - Or I ask Catalin to only pull the arm64 part *minus the Kconfig*, and
>> only merge this last bit when the dependencies are satisfied in Linus' tree.
>>
>> What do you guys think?
>>
> I would think you would prefer option (1) to get the code in cleaner.
> Both the KVM/next tree is stable and I can provide you with a stable
> KVM/ARM tree. But I really don't feel strongly about this.

That'd be my preferred choice too. Let's see what the KVM maintainers'
position on that.

Thanks,

	M.
-- 
Jazz is not dead. It just smells funny...

Planning the merge of KVM/arm64

[Paolo Bonzini]

Il 04/06/2013 16:59, Marc Zyngier ha scritto:
>>> >> - Either I can rely on a stable branch from both KVM and KVM/ARM trees
>>> >> on which I can base my tree for Catalin/Will to pull,
>>> >> - Or I ask Catalin to only pull the arm64 part *minus the Kconfig*, and
>>> >> only merge this last bit when the dependencies are satisfied in Linus' tree.
>>> >>
>>> >> What do you guys think?
>>> >>
>> > I would think you would prefer option (1) to get the code in cleaner.
>> > Both the KVM/next tree is stable and I can provide you with a stable
>> > KVM/ARM tree. But I really don't feel strongly about this.
> That'd be my preferred choice too. Let's see what the KVM maintainers'
> position on that.

I wonder if Linus would complain about irrelevant KVM changes in
Will/Catalin's pull request.  The KVM/next tree has other patches below
the ones you need.

What we usually do for x86 is get an Acked-by from the other part.  If
there are no dependencies on other aarch64 core changes, it'd be better
to go through the KVM tree.  Otherwise separating the Kconfig change
should be okay (perhaps add it with depends on BROKEN, and remove the
dependency later?).

Paolo

Planning the merge of KVM/arm64

[Will Deacon]

On Tue, Jun 04, 2013 at 04:30:52PM +0100, Paolo Bonzini wrote:
> Il 04/06/2013 16:59, Marc Zyngier ha scritto:
> >>> >> - Either I can rely on a stable branch from both KVM and KVM/ARM trees
> >>> >> on which I can base my tree for Catalin/Will to pull,
> >>> >> - Or I ask Catalin to only pull the arm64 part *minus the Kconfig*, and
> >>> >> only merge this last bit when the dependencies are satisfied in Linus' tree.
> >>> >>
> >>> >> What do you guys think?
> >>> >>
> >> > I would think you would prefer option (1) to get the code in cleaner.
> >> > Both the KVM/next tree is stable and I can provide you with a stable
> >> > KVM/ARM tree. But I really don't feel strongly about this.
> > That'd be my preferred choice too. Let's see what the KVM maintainers'
> > position on that.
> 
> I wonder if Linus would complain about irrelevant KVM changes in
> Will/Catalin's pull request.  The KVM/next tree has other patches below
> the ones you need.
> 
> What we usually do for x86 is get an Acked-by from the other part.  If
> there are no dependencies on other aarch64 core changes, it'd be better
> to go through the KVM tree.  Otherwise separating the Kconfig change
> should be okay (perhaps add it with depends on BROKEN, and remove the
> dependency later?).

Well you can certainly have my ack for the series but, as you say, it
depends whether there are further dependencies on patches queued for aarch64
core. For 3.11, conflicts with Steve's (CC'd) hugetlb stuff are likely.

  Acked-by: Will Deacon <will.deacon@arm.com>

Will

Planning the merge of KVM/arm64

[Steve Capper]

On Tue, Jun 04, 2013 at 04:40:23PM +0100, Will Deacon wrote:
> On Tue, Jun 04, 2013 at 04:30:52PM +0100, Paolo Bonzini wrote:
> > Il 04/06/2013 16:59, Marc Zyngier ha scritto:
> > >>> >> - Either I can rely on a stable branch from both KVM and KVM/ARM trees
> > >>> >> on which I can base my tree for Catalin/Will to pull,
> > >>> >> - Or I ask Catalin to only pull the arm64 part *minus the Kconfig*, and
> > >>> >> only merge this last bit when the dependencies are satisfied in Linus' tree.
> > >>> >>
> > >>> >> What do you guys think?
> > >>> >>
> > >> > I would think you would prefer option (1) to get the code in cleaner.
> > >> > Both the KVM/next tree is stable and I can provide you with a stable
> > >> > KVM/ARM tree. But I really don't feel strongly about this.
> > > That'd be my preferred choice too. Let's see what the KVM maintainers'
> > > position on that.
> > 
> > I wonder if Linus would complain about irrelevant KVM changes in
> > Will/Catalin's pull request.  The KVM/next tree has other patches below
> > the ones you need.
> > 
> > What we usually do for x86 is get an Acked-by from the other part.  If
> > there are no dependencies on other aarch64 core changes, it'd be better
> > to go through the KVM tree.  Otherwise separating the Kconfig change
> > should be okay (perhaps add it with depends on BROKEN, and remove the
> > dependency later?).
> 
> Well you can certainly have my ack for the series but, as you say, it
> depends whether there are further dependencies on patches queued for aarch64
> core. For 3.11, conflicts with Steve's (CC'd) hugetlb stuff are likely.
> 
>   Acked-by: Will Deacon <will.deacon@arm.com>
> 
> Will
> 

I'd be happy to rebase/test the aarch64 huge page code against a branch if
that's helpful?

Cheers,
-- 
Steve

Planning the merge of KVM/arm64

[Marc Zyngier]

On 04/06/13 16:30, Paolo Bonzini wrote:

Hi Paolo,

> Il 04/06/2013 16:59, Marc Zyngier ha scritto:
>>>>>> - Either I can rely on a stable branch from both KVM and
>>>>>> KVM/ARM trees on which I can base my tree for Catalin/Will
>>>>>> to pull, - Or I ask Catalin to only pull the arm64 part
>>>>>> *minus the Kconfig*, and only merge this last bit when the
>>>>>> dependencies are satisfied in Linus' tree.
>>>>>> 
>>>>>> What do you guys think?
>>>>>> 
>>>> I would think you would prefer option (1) to get the code in
>>>> cleaner. Both the KVM/next tree is stable and I can provide you
>>>> with a stable KVM/ARM tree. But I really don't feel strongly
>>>> about this.
>> That'd be my preferred choice too. Let's see what the KVM
>> maintainers' position on that.
> 
> I wonder if Linus would complain about irrelevant KVM changes in 
> Will/Catalin's pull request.  The KVM/next tree has other patches
> below the ones you need.

That's how the ARM tree is dealt with most of the time. We create stable
branches (that we know for sure are going in at the next merge window)
that are used as a base for others to base their own developments.
KVM/ARM has been merged like this, using something crazy like half a
dozen stable branches from different contributors... So far, Linus
hasn't complained.

KVM/arm64 is not that bad in that respect, but I'm inclined to follow
the same process.

> What we usually do for x86 is get an Acked-by from the other part.
> If there are no dependencies on other aarch64 core changes, it'd be
> better to go through the KVM tree.

There is a number of potential additions to the arm64 tree that may
conflict with KVM/arm64 (THP comes to my mind...).

> Otherwise separating the Kconfig change should be okay (perhaps add
> it with depends on BROKEN, and remove the dependency later?).

Could do, yes.

Thanks,

	M.
-- 
Jazz is not dead. It just smells funny...

Planning the merge of KVM/arm64

[Christoffer Dall]

On 4 June 2013 08:30, Paolo Bonzini <pbonzini@redhat.com> wrote:
> Il 04/06/2013 16:59, Marc Zyngier ha scritto:
>>>> >> - Either I can rely on a stable branch from both KVM and KVM/ARM trees
>>>> >> on which I can base my tree for Catalin/Will to pull,
>>>> >> - Or I ask Catalin to only pull the arm64 part *minus the Kconfig*, and
>>>> >> only merge this last bit when the dependencies are satisfied in Linus' tree.
>>>> >>
>>>> >> What do you guys think?
>>>> >>
>>> > I would think you would prefer option (1) to get the code in cleaner.
>>> > Both the KVM/next tree is stable and I can provide you with a stable
>>> > KVM/ARM tree. But I really don't feel strongly about this.
>> That'd be my preferred choice too. Let's see what the KVM maintainers'
>> position on that.
>
> I wonder if Linus would complain about irrelevant KVM changes in
> Will/Catalin's pull request.  The KVM/next tree has other patches below
> the ones you need.
>
> What we usually do for x86 is get an Acked-by from the other part.  If
> there are no dependencies on other aarch64 core changes, it'd be better
> to go through the KVM tree.  Otherwise separating the Kconfig change
> should be okay (perhaps add it with depends on BROKEN, and remove the
> dependency later?).
>
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.

-Christoffer

Planning the merge of KVM/arm64

[Paolo Bonzini]

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.

Paolo

Planning the merge of KVM/arm64

[Gleb Natapov]

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?

--
			Gleb.

Planning the merge of KVM/arm64

[Christoffer Dall]

On 4 June 2013 09:37, Gleb Natapov <gleb@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?

-Christoffer

Planning the merge of KVM/arm64

[Gleb Natapov]

On Tue, Jun 04, 2013 at 10:57:32PM -0700, Christoffer Dall wrote:
> On 4 June 2013 09:37, Gleb Natapov <gleb@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.

--
			Gleb.

Planning the merge of KVM/arm64

[Catalin Marinas]

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@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.

As we discussed some time ago, after the core arm64 KVM is merged you
will use the same workflow as for arm (merge via the kvm tree).

Thanks.

-- 
Catalin

Planning the merge of KVM/arm64

[Gleb Natapov]

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@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.

> As we discussed some time ago, after the core arm64 KVM is merged you
> will use the same workflow as for arm (merge via the kvm tree).
> 
> Thanks.
> 
> -- 
> Catalin

--
			Gleb.

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@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...