On 25.11.2013, at 16:49, Anup Patel <anup.patel@xxxxxxxxxx> wrote: > Currently, we don't have an exit reason for VM reset emulation > in user space hence this patch adds exit reason KVM_EXIT_RESET > for this purpose. > > This newly added KVM_EXIT_RESET will be used by KVM arm/arm64 > in-kernel PSCI support to reset VMs. > > Signed-off-by: Anup Patel <anup.patel@xxxxxxxxxx> > Signed-off-by: Pranavkumar Sawargaonkar <pranavkumar@xxxxxxxxxx> > --- > include/uapi/linux/kvm.h | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/include/uapi/linux/kvm.h b/include/uapi/linux/kvm.h > index 902f124..64a04cc 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_RESET 24 I have to admit that I'm not particularly happy with the exit name. It's not obvious from the name under which circumstances it gets triggered. Does it get triggered when a core level reset happens? Does it get triggered when a system level reset happened? When the guest requests one? I know what it does, but I find the name too generic for what it is. What you're really doing is introduce a new communication channel in parallel to MMIO / PIO / HCALL which is only used for system level reset / shutdown today. Can we treat it as such? Could you please make this a common exit number that's called something like KVM_EXIT_SYSTEM_EVENT with a parameter that can either be TRIGGER_SHUTDOWN or TRIGGER_RESET. That way it's obvious what's going on and people don't get confused. Alex _______________________________________________ kvmarm mailing list kvmarm@xxxxxxxxxxxxxxxxxxxxx https://lists.cs.columbia.edu/cucslists/listinfo/kvmarm