[RFC PATCH 2/2] ARM: SMP support for mach-virt
From: Marc Zyngier <hidden>
Date: 2012-12-04 17:24:57
On 04/12/12 17:16, Will Deacon wrote:
On Tue, Dec 04, 2012 at 04:45:58PM +0000, Rob Herring wrote:quoted
On 12/04/2012 10:11 AM, Will Deacon wrote:quoted
On Tue, Dec 04, 2012 at 02:37:25PM +0000, Russell King - ARM Linux wrote:quoted
Umm. So let's see. If I'm running v3.6 stock kernel and want to kexec into a v3.7 stock kernel. The SMP pen is part of the v3.6 kernel, which will be located at 32K into the RAM. The v3.7 kernel will also want to occupy the same place. At some point you have to overwrite the v3.6 kernel with the v3.7 kernel image.If the 3.6 kernel didn't bring those CPUs online, they will sit in the bootloader pen (out of the way of the kernel image) rather than the kernel pen so I don't think there will be a problem. The problem you're describing actually happens when the 3.6 kernel onlines all of the CPUs, because now it has no way to hotplug them off safely. This is also an issue with non-virtualised hardware but we could solve it for the virtual platform by having a para-virtualised device for doing CPU hotplug.quoted
That happens _before_ the DT has been parsed, so any memreserve stuff will be ignored. And it's at that point that your "offline" secondary CPUs will have their instructions overwritten. That's fine if the pen ends up being at the same place but that's not something we guarantee.Having CPUs in limbo between the bootloader the being online in the kernel is something we should just avoid. Isn't that pen __init anyway?Aren't we mixing 2 pens here? You must have some simple bootloader containing vector table and a pen that the dtb points to, right? The pen you have in the kernel is only needed when hotplug only does a wfi. As you don't yet support hotplug, then you can drop all the kernel pen code.Yes, both qemu and kvmtool have bootloader pens outside of the kernel but since wfi is not trapped by kvm, the secondaries can be released early due to a spurious wakeup so we need the second pen.
Actually, KVM traps WFI and puts the vcpu thread on a wait queue (we are actually giving more guaranties than the architecture offers here). We should be able to remove the loop and rely on WFI. M. -- Jazz is not dead. It just smells funny...