On 15.07.2013, at 14:24, Gleb Natapov wrote: > On Mon, Jul 15, 2013 at 02:21:51PM +0200, Alexander Graf wrote: >> >> On 15.07.2013, at 14:15, Gleb Natapov wrote: >> >>> On Mon, Jul 15, 2013 at 01:44:46PM +0200, Alexander Graf wrote: >>>> >>>> On 15.07.2013, at 13:30, Gleb Natapov wrote: >>>> >>>>> On Mon, Jul 15, 2013 at 04:41:17PM +0530, Bharat Bhushan wrote: >>>>>> KVM_HC_VM_RESET: Requests that the virtual machine be reset. >>>>>> KVM_HC_VM_SHUTDOWN: Requests that the virtual machine be powered-off/halted. >>>>>> >>>>>> These hcalls are handled by guest userspace. >>>>>> >>>>>> Signed-off-by: Bharat Bhushan <bharat.bhushan@xxxxxxxxxxxxx> >>>>>> --- >>>>>> Documentation/virtual/kvm/hypercalls.txt | 16 ++++++++++++++++ >>>>>> include/uapi/linux/kvm_para.h | 3 ++- >>>>>> 2 files changed, 18 insertions(+), 1 deletions(-) >>>>>> >>>>>> diff --git a/Documentation/virtual/kvm/hypercalls.txt b/Documentation/virtual/kvm/hypercalls.txt >>>>>> index ea113b5..58acdc1 100644 >>>>>> --- a/Documentation/virtual/kvm/hypercalls.txt >>>>>> +++ b/Documentation/virtual/kvm/hypercalls.txt >>>>>> @@ -64,3 +64,19 @@ Purpose: To enable communication between the hypervisor and guest there is a >>>>>> shared page that contains parts of supervisor visible register state. >>>>>> The guest can map this shared page to access its supervisor register through >>>>>> memory using this hypercall. >>>>>> + >>>>>> +5. KVM_HC_VM_RESET >>>>>> +------------------------ >>>>>> +Architecture: PPC >>>>>> +Status: active >>>>>> +Purpose: Requests that the virtual machine be reset. The hcall takes no >>>>>> +arguments. If successful the hcall does not return. If an error occurs it >>>>>> +returns EV_INTERNAL. >>>>>> + >>>>>> +6. KVM_HC_VM_SHUTDOWN >>>>>> +------------------------ >>>>>> +Architecture: PPC >>>>>> +Status: active >>>>>> +Purpose: Requests that the virtual machine be powered-off/halted. >>>>>> +The hcall takes no arguments. If successful the hcall does not return. >>>>>> +If an error occurs it returns EV_INTERNAL. >>>>>> diff --git a/include/uapi/linux/kvm_para.h b/include/uapi/linux/kvm_para.h >>>>>> index cea2c5c..218882d 100644 >>>>>> --- a/include/uapi/linux/kvm_para.h >>>>>> +++ b/include/uapi/linux/kvm_para.h >>>>>> @@ -19,7 +19,8 @@ >>>>>> #define KVM_HC_MMU_OP 2 >>>>>> #define KVM_HC_FEATURES 3 >>>>>> #define KVM_HC_PPC_MAP_MAGIC_PAGE 4 >>>>>> - >>>>>> +#define KVM_HC_VM_RESET 5 >>>>>> +#define KVM_HC_VM_SHUTDOWN 6 >>>>> There is no much sense to share hypercalls between architectures. There >>>>> is zero probability x86 will implement those for instance (not sure >>>>> why PPC will want them either instead of emulating devices that do >>>>> shutdown/reset >>>> >>>> Implementing devices gets pretty tricky. Usually all of your devices sit on the SoC with a strictly defined layout. We can randomly shove some device in there, but there's a good chance we're overlapping with another device. >>>> >>> I thought we have device trees to sort these things out. >> >> For Linux guests, yes :). For proprietary random other guests, no. >> > But those can't use hcalls too, no? Why not? There are customers out there who are more than happy to add functionality, but not change functionality. Alex -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
