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 <[email protected]>
> >>>> ---
> >>>> 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?
> >
> >> So having a separate namespace with hcalls makes things a lot easier. And
> >> the guest needs to learn how to access it either way.
> >>
> >>> ). So lets move them to arch headers.
> >>
> >> Do we want to keep the numbering scheme interchangable? Maybe there will
> >> be hcalls that can get shared between archs? If so, leaving it in the same
> >> header file might make sense.
> >>
> > hcalls will not be handled in shared code, so I do not see why would we
> > want to have interchangable numbering scheme. hcalls handlers of
> > different arches can call common code after intercepting hcall and
> > retrieving arguments from an arch vcpu state.
>
> Works for me, but then we should make hcall numbers 100% arch specific and
> have no global hc namespace anymore.
>
Yes, of course. Move all of them to arch headers.
--
Gleb.
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
