Planning the merge of KVM/arm64
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.
Signature · 1 line
Jazz is not dead. It just smells funny...
Hi Marc,
Quoted 18 lines · 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/kvmWhat 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 tovirt/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)
Quoted 7 lines
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.
Quoted 1 line
From my side, +1 for the second option that is "pull the arm64 part *minus
the Kconfig*, and ..."
Quoted 4 lines
Thanks,
M.
Quoted 8 lines
--
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
On 04/06/13 14:13, Anup Patel wrote:
Hi Anup,
Quoted 25 lines · Marc Zyngier
Quoted 24 lines
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/kvmWhat 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 tovirt/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.
Quoted 7 lines
Quoted 1 line
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.
Signature · 1 line
Jazz is not dead. It just smells funny...
Quoted 29 lines · Anup Patel
Hi Marc,
Quoted 18 lines · 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/kvmWhat 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 tovirt/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)Quoted 7 lines
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?
Quoted 8 lines
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.
Signature · 1 line
Catalin
Quoted 6 lines · 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.
huh?
Quoted 12 lines
For reference, it is sitting there:
git://git.kernel.org/pub/scm/linux/kernel/git/maz/arm-platforms.git
kvm-arm64/kvmWhat 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 tovirt/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)
Quoted 8 lines
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
Quoted 9 lines · Christoffer Dall
Quoted 6 lines · 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.
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... ;-)
Quoted 18 lines
Quoted 18 lines
For reference, it is sitting there:
git://git.kernel.org/pub/scm/linux/kernel/git/maz/arm-platforms.git
kvm-arm64/kvmWhat 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 tovirt/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.
Quoted 5 lines
Quoted 2 lines
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.
Signature · 1 line
Jazz is not dead. It just smells funny...
Paolo Bonzini
maintainerIl 04/06/2013 16:59, Marc Zyngier ha scritto:
Quoted 5 lines
Quoted 5 lines
Quoted 5 lines
Quoted 5 lines
Quoted 5 lines
- 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.
Quoted 7 lines
Quoted 5 lines
Quoted 5 lines
Quoted 2 lines
Quoted 2 lines
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
Will Deacon
Acked-byQuoted 18 lines · Paolo Bonzini
Il 04/06/2013 16:59, Marc Zyngier ha scritto:
Quoted 5 lines
Quoted 5 lines
Quoted 5 lines
Quoted 5 lines
Quoted 5 lines
- 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.Quoted 7 lines
Quoted 5 lines
Quoted 5 lines
Quoted 2 lines
Quoted 2 lines
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.
Quoted 5 lines
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
Kconfigchange 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.
Will
Quoted 25 lines · Will Deacon
Quoted 18 lines · Paolo Bonzini
Il 04/06/2013 16:59, Marc Zyngier ha scritto:
Quoted 5 lines
Quoted 5 lines
Quoted 5 lines
Quoted 5 lines
Quoted 5 lines
- 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.Quoted 7 lines
Quoted 5 lines
Quoted 5 lines
Quoted 2 lines
Quoted 2 lines
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.
Quoted 5 lines
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
Kconfigchange should be okay (perhaps add it with depends on BROKEN, and remove the dependency later?).
Quoted 8 lines
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 <[email protected]>Will
I'd be happy to rebase/test the aarch64 huge page code against a branch if that's helpful?
Cheers,
Signature · 1 line
Steve
On 04/06/13 16:30, Paolo Bonzini wrote:
Hi Paolo,
Quoted 13 lines
Il 04/06/2013 16:59, Marc Zyngier ha scritto:
Quoted 12 lines
Quoted 12 lines
Quoted 12 lines
Quoted 8 lines
Quoted 8 lines
- 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.
Quoted 6 lines
Quoted 2 lines
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.
Quoted 3 lines
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...).
Quoted 2 lines
Otherwise separating the
Kconfigchange should be okay (perhaps add it with depends on BROKEN, and remove the dependency later?).
Could do, yes.
Thanks,
M.
Signature · 1 line
Jazz is not dead. It just smells funny...
Quoted 18 lines · Paolo Bonzini
Il 04/06/2013 16:59, Marc Zyngier ha scritto:
Quoted 5 lines
Quoted 5 lines
Quoted 5 lines
Quoted 5 lines
Quoted 5 lines
- 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.Quoted 7 lines
Quoted 5 lines
Quoted 5 lines
Quoted 2 lines
Quoted 2 lines
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.
Quoted 6 lines
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
Kconfigchange 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
Paolo Bonzini
maintainerIl 04/06/2013 17:43, Christoffer Dall ha scritto:
Quoted 7 lines
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?
Quoted 7 lines
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
Kconfighack, imho.
Ok, let's see what Gleb says.
Paolo
Quoted 12 lines · Paolo Bonzini
Il 04/06/2013 17:43, Christoffer Dall ha scritto:
Quoted 11 lines
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.
Quoted 6 lines
Quoted 3 lines
It's a pretty clean implementation with quite few dependencies and merging as a working series should be a priority instead of the
Kconfighack, 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.
Quoted 17 lines · Gleb Natapov
Quoted 16 lines · Paolo Bonzini
Il 04/06/2013 17:43, Christoffer Dall ha scritto:
Quoted 14 lines
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
Kconfighack, imho.
Quoted 7 lines
Quoted 2 lines
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
Quoted 18 lines · Christoffer Dall
Quoted 17 lines · Gleb Natapov
Quoted 16 lines · Paolo Bonzini
Il 04/06/2013 17:43, Christoffer Dall ha scritto:
Quoted 14 lines
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
Kconfighack, imho.
Quoted 9 lines
Quoted 7 lines
Quoted 2 lines
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.
Quoted 26 lines · Gleb Natapov
Quoted 25 lines · Christoffer Dall
Quoted 24 lines · Gleb Natapov
Quoted 12 lines · Paolo Bonzini
Il 04/06/2013 17:43, Christoffer Dall ha scritto:
Quoted 11 lines
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.
Quoted 6 lines
Quoted 3 lines
It's a pretty clean implementation with quite few dependencies and merging as a working series should be a priority instead of the
Kconfighack, 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?
Quoted 4 lines
Quoted 2 lines
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.
Signature · 1 line
Catalin
Quoted 29 lines · Catalin Marinas
Quoted 28 lines · Gleb Natapov
Quoted 27 lines · Christoffer Dall
Quoted 17 lines · Gleb Natapov
Quoted 16 lines · Paolo Bonzini
Il 04/06/2013 17:43, Christoffer Dall ha scritto:
Quoted 14 lines
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
Kconfighack, imho.Quoted 7 lines
Quoted 2 lines
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?
Quoted 9 lines
Quoted 2 lines
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
Kconfigpatch enabling it. This branch would be based on mainline rather than kvm/next. Once your code goes in mainline, I'll just push theKconfigentry (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.
Quoted 7 lines
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.
Signature · 1 line
Catalin
--
Gleb.
Quoted 33 lines · Gleb Natapov
Quoted 32 lines · Catalin Marinas
Quoted 30 lines · Gleb Natapov
Quoted 18 lines · Christoffer Dall
Quoted 17 lines · Gleb Natapov
Quoted 16 lines · Paolo Bonzini
Il 04/06/2013 17:43, Christoffer Dall ha scritto:
Quoted 14 lines
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
Kconfighack, imho.Quoted 9 lines
Quoted 7 lines
Quoted 2 lines
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.
Quoted 8 lines
Quoted 6 lines
I think it's better if I push the bulk of the arm64 KVM branch but without
Kconfigpatch enabling it. This branch would be based on mainline rather than kvm/next. Once your code goes in mainline, I'll just push theKconfigentry (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.
Signature · 1 line
Jazz is not dead. It just smells funny...