On 17/10/13 07:45, Anup Patel wrote: > On Thu, Oct 17, 2013 at 3:41 AM, Christoffer Dall > <christoffer.dall@xxxxxxxxxx> wrote: >> On Wed, Oct 16, 2013 at 10:32:30PM +0530, Anup Patel wrote: >>> Update user space API interface headers for providing information to >>> user space needed to emulate PSCI function calls in user space (i.e. >>> QEMU or KVMTOOL). >>> >>> Signed-off-by: Anup Patel <anup.patel@xxxxxxxxxx> >>> Signed-off-by: Pranavkumar Sawargaonkar <pranavkumar@xxxxxxxxxx> >>> --- >>> include/uapi/linux/kvm.h | 7 +++++++ >>> 1 file changed, 7 insertions(+) >>> >>> diff --git a/include/uapi/linux/kvm.h b/include/uapi/linux/kvm.h >>> index e32e776..dae2664 100644 >>> --- a/include/uapi/linux/kvm.h >>> +++ b/include/uapi/linux/kvm.h >>> @@ -171,6 +171,7 @@ struct kvm_pit_config { >>> #define KVM_EXIT_WATCHDOG 21 >>> #define KVM_EXIT_S390_TSCH 22 >>> #define KVM_EXIT_EPR 23 >>> +#define KVM_EXIT_PSCI 24 >>> >>> /* For KVM_EXIT_INTERNAL_ERROR */ >>> /* Emulate instruction failed. */ >>> @@ -301,6 +302,12 @@ struct kvm_run { >>> struct { >>> __u32 epr; >>> } epr; >>> + /* KVM_EXIT_PSCI */ >>> + struct { >>> + __u32 fn; >>> + __u64 args[7]; >>> + __u64 ret[4]; >>> + } psci; >>> /* Fix the size of the union. */ >>> char padding[256]; >>> }; >>> -- >>> 1.7.9.5 >>> >> I am also wondering if this is not solving a very specific need without >> thinking a little more carefully about this problem. > > No, its not solving a specific problem. > > In fact, its more general because we pass complete info required to > emulate a PSCI call in user space. > (Please refer PSCI calling convention) > >> >> We have previously discussed the need for some secure side emulation >> in QEMU, and I think perhaps we need something more generic which allows >> user space to handle SMC calls and/or allows user space to "inject" some >> secure world runtime that the kernel can run in a partially or fully >> isolated container to handle SMC calls. >> >> Peter raised this issue previously and pointed to a proposal he had as >> well. > > If required we can have an additional field in kvm_run->psci which tells > whether the PSCI call is an SMC call or HVC call. > >> >> Is there a technical reason why we need something specifically directed >> to PSCI? > > Its quite natural to add this to PSCI emulation in KVM ARM/ARM64 instead > of adding a separate VirtIO device for System reboot and System poweroff. > > Also in the process of implementing SYSTEM_OFF and SYSTEM_RESET > emulation in user space we would also have an infrastructure for adding > emulation of new PSCI calls in user space. And I strongly oppose to that. It creates consistency issues (what if userspace implements one version of PSCI, and the kernel another?), and also some really horrible situations: Imagine you implement the SUSPEND operation in userspace, and want to wake the vcpu up with an interrupt. You'd end-up having to keep track of the state in the kernel, having to forward the interrupt event to userspace... So really, no. M. -- Jazz is not dead. It just smells funny... _______________________________________________ kvmarm mailing list kvmarm@xxxxxxxxxxxxxxxxxxxxx https://lists.cs.columbia.edu/cucslists/listinfo/kvmarm