On Mon, Jul 15, 2019 at 03:26:39PM +0100, James Morse wrote: > On 15/07/2019 14:48, Mark Rutland wrote: > > On Mon, Jul 15, 2019 at 02:41:00PM +0100, Dave Martin wrote: > >> One option (suggested to me by James Morse) would be to allow userspace > >> to disable in the in-kernel PSCI implementation and provide its own > >> PSCI to the guest via SMC -- in which case userspace that wants to > >> implement SDEI would have to implement PSCI as well. > > > > I think this would be the best approach, since it puts userspace in > > charge of everything. > > > > However, this interacts poorly with FW-based mitigations that we > > implement in hyp. I suspect we'd probably need a mechanism to delegate > > that responsibility back to the kernel, and figure out if that has any > > interaction with thigns that got punted to userspace... > > This has come up before: > https://lore.kernel.org/r/59C139D0.3040507@xxxxxxx > > I agree Qemu should opt-in to this, it needs to be a feature that is enabled. > > I had an early version of something like this for testing SDEI before > there was firmware available. The review feedback from Christoffer was > that it should include HVC and SMC, their immediates, and shouldn't be > tied to SMC-CC ranges. > > I think this should be a catch-all as Heyi describes to deliver > 'unhandled SMC/HVC' to user-space as hypercall exits. We should > include the immediate in the struct. > > We can allow Qemu to disable the in-kernel PSCI implementation, which > would let it be done in user-space via this catch-all mechanism. (PSCI > in user-space has come up on another thread recently). The in-kernel > PSCI needs to be default-on for backwards compatibility. > > As Mark points out, the piece that's left is the 'arch workaround' > stuff. We always need to handle these in the kernel. I don't think > these should be routed-back, they should be un-obtainable by > user-space. Sure; I meant that those should be handled in the kernel rather than going to host userspace and back. I was suggesting was that userspace would opt into taking ownership of all HVC calls, then explicitly opt-in to the kernel handling specific (sets of) calls. There are probably issues with that, but I suspect defining "all undandled calls" will be problematic otherwise. Thanks, Mark. _______________________________________________ kvmarm mailing list kvmarm@xxxxxxxxxxxxxxxxxxxxx https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
