[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [XenARM] [RFC PATCH 2/2] ARM: SMP support for mach-virt
On Tue, Dec 04, 2012 at 01:33:26PM +0000, Russell King - ARM Linux wrote: > On Tue, Dec 04, 2012 at 12:40:47PM +0000, Will Deacon wrote: > > On Mon, Dec 03, 2012 at 09:55:35PM +0000, Rob Herring wrote: > > > Why is the pen is needed? It should only be needed for hotplug on > > > systems that can't reset their cores. I'd hope you could design good > > > virtual h/w. > > > > It's not so much about designing good virtual h/w as it is avoiding tying > > the platform to it. What we don't want is to mandate that in order to boot > > this machine, you *must* implement an emulation of some virtual > > power-controller or SMP booting device. If we go down that route, there's > > less advantage from having the virtual platform in the first place. > > There is actually a bigger problem here. Let's say that you have a > quad SMP platform. You've arranged for your kernel to boot and only > bring one of those cores online. > > You then kexec() or reboot. As far as the kernel is concerned, those > other two CPUs are not online and are not running any kernel code; > however in reality they could be sitting in this 'pen'. > > The memory that these 'offline' CPUs is executing then gets overwritten, > and that's game over for those CPUs. That's not strictly true. The device-tree passed to the kernel should have a /memreserve/ entry for the SMP pen to avoid exactly this scenario. In real hardware, this still sucks because you have spinning CPUs burning up power but that's not such a problem with a virtual platform. > So, the 'pen' approach in the kernel is fragile, I'd much rather not > have it. It was fine in the beginning for the initial ARM Ltd SMP > platforms but in this modern age it has no place in real platforms where > there is proper control of the secondary CPUs. We could have an (optional) virtual device for booting secondary CPUs but I think the pen should still be there as a default method. Otherwise, we're forcing a component of the platform to be emulated unnecessarily (the CPU, vGIC and timers all have hardware-assisted virtualisation and require no emulation). Will _______________________________________________ Xen-arm mailing list Xen-arm@xxxxxxxxxxxxx http://lists.xen.org/cgi-bin/mailman/listinfo/xen-arm
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |