On Mon, Dec 1, 2014 at 5:47 AM, Radim Krčmář <rkrcmar@xxxxxxxxxx> wrote: > 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. Consider: All the arch specific defines were defined in asm/kvm_para.h. Each asm/kvm_para.h defines KVM_HC_ARCH_MAX as a relative index from which generic hypercalls ought to be applied (e.g. KVM_HC_ARCH_MAX+1 rather than 11). This would at least organize the hypercalls and avoid a situation in which a number of hypercalls which are not applicable pollute the namespace. I'll grant that the grounds here may be largely aesthetic. The other worry is that institutionalization of this method will lead to a hesitance to associate a specific hypercall index with anything other than the function which it has been assigned in past kernel revisions. In addition, this leads to a maintenance problem for anyone seeking to add a hypercall in the future in which their hypercalls will need to be updated in order to avoid collisions with the community as well as any other sources they may be dealing with. These are all minor headaches, but they can be avoided. A registration method like this -- albeit somewhat more refined -- could be used to eliminate all of those headaches in my opinion. > 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? Virtio has several limitations. It implies a situation in which the system has already booted. Secondly, there's no easy way to access the kvm structure. Thirdly, it cannot be used effectively to implement an optimization for virtualization on a platform. Fourthly, I believe it would require changes to qemu command lines -- and any associated tools which might be used to cobble together a qemu command line. A simple way of putting it, using the existing in-kernel code: I don't see how you could use virtio to map the powerpc magic page at bootup. >> 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.) I'm not sure which conflict you mean. I presume you mean the possibility that two separate modules may attempt to claim the same hypercall index? Presuming you do -- and I may be arguing a straw man here -- I'm not sure that's classifiable as a design flaw as no method occurs to me by which one could add the capability of dynamically registering a hypercall and have access to the capabilities I mentioned above. However, I can be trivially proven wrong by the suggestion of a design by which an out-of-tree module could dynamically register a hypercall, have access to the kvm structure (at a minimum), and avoid the possibility that some other user may race to claim that hypercall. >> "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
