Avi, Gregory Haskins wrote: > > Todo: > *) Develop some kind of hypercall registration mechanism for KVM so that > we can use that as an integration point instead of directly hooking > kvm hypercalls > What would you like to see here? I now remember why I removed the original patch I had for registration...it requires some kind of discovery mechanism on its own. Note that this is hard, but I figured it would make the overall series simpler if I didn't go this route and instead just integrated with a statically allocated vector. That being said, I have no problem adding this back in but figure we should discuss the approach so I don't go down a rat-hole ;) So, one thing we could do is use a string-identifier to discover hypercall resources. In this model, we would have one additional hypercall registered with kvm (in addition to the mmu-ops, etc) called KVM_HC_DYNHC or something like that. The support for DYNHC could be indicated in the cpuid (much like I do with the RESET, DYNIRQ, and VBUS support today. When hypercall provides register, the could provide a string such as "vbus", and they would be allocated a hypercall id. Likewise, the HC_DYNHC interface would allow a guest to query the cpuid for the DYNHC feature, and then query the HC_DYNHC vector for a string to hc# translation. If the provider is not present, we return -1 for the hc#, otherwise we return the one that was allocated. I know how you feel about string-ids in general, but I am not quite sure how to design this otherwise without it looking eerily similar to what I already have (which is registering a new HC vector in kvm_para.h) Thoughts? -Greg
Attachment:
signature.asc
Description: OpenPGP digital signature
