On Thu, Oct 17, 2013 at 10:21:11AM +0100, Marc Zyngier wrote: > On 17/10/13 10:10, Peter Maydell wrote: > > On 17 October 2013 09:37, Marc Zyngier <marc.zyngier@xxxxxxx> wrote: > >> On 16/10/13 18:02, Anup Patel wrote: > >>> The PSCI SYSTEM_OFF and SYSTEM_RESET functions are VM or Guest level > >>> functions hence cannot be emulated by the in-kernel PSCI emulation code. > >> > >> Why can't we implement system-wide functionality in the kernel? I fail > >> to see the issue here. > > > > Because the kernel isn't emulating the whole board, and you need > > to power off or reset the whole board, not just the CPUs. > > In which case we can forward a generic event, once KVM has dealt with > the CPUs. > > >> I'm really not keen on this approach. Having part of the PSCI > >> implementation offloaded to userspace means we don't have a complete > >> implementation in KVM anymore, and we end-up duplicating functionality > >> all over the place. > >> > >> Also, OFF and RESET are not PSCI specific concepts, and could be > >> implemented in various ways. I'm more inclined to return a > >> *standardized* exit code that the various platforms can interpret. > > > > Maybe we should have a more generic "kernel can't handle this, > > toss it to userspace" API? That might also fit in with supporting > > guests that want to make SMC calls to an emulated monitor... > > Indeed. > Agreed as well. That's what I was trying to say with a more generic solution, and exiting on a subset of SMC/HVC calls for PSCI is a weird compromise. After all, PSCI is nothing more than acting on SMC or HVC calls, and I'm quite sure there will be a need for user space to emulate handling of SMC calls sooner or later, and that is the interface we need. We may end up with both kernel and user space support for PSCI in that case, but naturally it would always be *either* the kernel handling the whole thing, *or* user space handling the whole thing. In both cases we may need extra functionality to communicate between user space and KVM, such as suspending a vcpu from user space and waking it up on in-kernel generated timer interrupts, or, conversely, telling user space that there was a PSCI call to turn off the system. >From my point of view the most difficult part to figure out is how to support general handling of secure monitor services in user space. I don't see any particular problems with expanding the exit reasons with things like "turn off VM" or "reset VM"? -Christoffer _______________________________________________ kvmarm mailing list kvmarm@xxxxxxxxxxxxxxxxxxxxx https://lists.cs.columbia.edu/cucslists/listinfo/kvmarm
