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)