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? 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. 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. 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. -Phil "The generation of random numbers is too important to be left to chance." -Robert R. Coveyou, Oak Ridge National Laboratory, 1969 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?) -Phil "The generation of random numbers is too important to be left to chance." -Robert R. Coveyou, Oak Ridge National Laboratory, 1969 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
