Gregory Haskins wrote:
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 ;)
One idea is similar to signalfd() or eventfd(). Provide a kvm ioctl
that takes a gsi and returns an fd. Writes to the fd change the state
of the line, possible triggering an interrupt. Another ioctl takes a
hypercall number or pio port as well as an existing fd. Invocations of
the hypercall or writes to the port write to the fd (using the same
protocol as eventfd), so the other end can respond.
The nice thing is that this can be used by both kernel and userspace
components, and for kernel components, hypercalls can be either buffered
or unbuffered.
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)
No need for a string ID. Reserve a range of hypercall numbers for
dynamic IDs. Userspace allocates one and gives it to the device using
its configuration space (as applies to whatever bus it is using).
--
Do not meddle in the internals of kernels, for they are subtle and quick to panic.
--
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
