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@xxxxxxxxxx> 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@xxxxxxxxxx> > >> --- > > > > 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?) -- 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
