Re: [PATCH] KVM: Introduce dynamically registered hypercall capability

["Radim Krčmář" <rkrcmar@redhat.com>]

2014-11-28 17:29-0800, Phil White:
> Good questions.
> 
> One thing that prompted this code is the presence and proliferation of
> architecture specific hypercalls in include/uapi/linux/kvm_para.h.
> I'm not sure why the tree has continued on for as long as it has with
> a list of reserved hypercall indices -- most of which are unused on
> any given architecture.  Is there a reason that I'm unaware of?

Name-space won't be exhausted, so nothing forced them to separate and
centralization easily avoids conflicts with generic hypercalls.

> This was written because I had a module which was meant to be loaded
> for paravirtualized VMs and it needed a hook to receive a hypercall.
> We originally reserved an index, but that struck me as sloppy for the
> same reason I mentioned before -- not every system is going to need
> that hypercall number reserved.

Makes sense;  out-of-tree modules are in an especially bad position to
get their hypercalls into the kernel.  (Is a hypercall necessary?)

> I didn't have a problem communicating the hypercall number to the
> guest incidentally -- it had a bit of shared memory where the request
> structure was placed.  That said, it could just as easily be used in a
> static arrangement where each request is made to claim a particular
> ID.

My main trouble is that we would export a very specific/limited feature
for an unknown problem -- we can't even tell if it is appropriate, which
strongly favors rejecting it.

I'd say that a virtio device is the way to go if you want to stay in the
kernel, but outside of kvm modules.  In which ways is virtio lacking?

> It does occur to me that in the absence of the setup which I had
> available, one could simply treat hc_nr as a 4 character ID rather
> than a particular digit.

(This would probably solve the situation in practice, but the conflict
 is still there, so design hasn't improved.)

> "The generation of random numbers is too important to be left to
> chance." -Robert R. Coveyou, Oak Ridge National Laboratory, 1969

:)  (Exactly.)

> On Thu, Nov 27, 2014 at 7:31 AM, Radim Krčmář <rkrcmar@redhat.com> wrote:
> > 2014-11-27 05:30-0800, Phil White:
> >> This introduces a list of entries which associate a function pointer of
> >> kvm_hc_type to a hypercall number and allows the ability to register and
> >> unregister entries.  In addition, it also allows the ability to retrieve a
> >> function pointer of kvm_hc_type for a given hypercall number which is meant
> >> to be called from the arch-specific section.
> >>
> >> The main intent is to allow modules to register hypercalls which they own
> >> rather than requiring the addition of a stub of some sort.  It will also
> >> allow each arch to maintain separate lists of hypercalls rather than having
> >> to respect changes in include/uapi/linux/kvm_para.h
> >>
> >> Signed-off-by: Phil White <pwhite@mvista.com>
> >> ---
> >
> > Apart from other problems,
> > how are guests going to use these hypercalls?
> >
> > (If hc_nr is dynamic, a guest doesn't know its number and even if it is
> >  static, someone could have registered it beforehand => this needs some
> >  kind of synchronization with host modules.  A hardcoded reservation?)