Gregory Haskins wrote:
I see. I had designed it slightly different where KVM could assign any
top level vector it wanted and thus that drove the guest-side interface
you see here to be more "generic hypercall". However, I think your
proposal is perfectly fine too and it makes sense to more narrowly focus
these calls as specifically "dynamic"...as thats the only vectors that
we could technically use like this anyway.
So rather than allocate a top-level vector, I will add "KVM_HC_DYNAMIC"
to kvm_para.h, and I will change the interface to follow suit (something
like s/hypercall/dynhc). Sound good?
Yeah.
Another couple of points:
- on the host side, we'd rig this to hit an eventfd. Nothing stops us
from rigging pio to hit an eventfd as well, giving us kernel handling
for pio trigger points.
- pio actually has an advantage over hypercalls with nested guests.
Since hypercalls don't have an associated port number, the lowermost
hypervisor must interpret a hypercall as going to a guest's hypervisor,
and not any lower-level hypervisors. What it boils down to is that you
cannot use device assignment to give a guest access to a virtio/vbus
device from a lower level hypervisor.
(Bah, that's totally unreadable. What I want is
instead of
hypervisor[eth0/virtio-server] ---->
intermediate[virtio-driver/virtio-server] ----> guest[virtio-driver]
do
hypervisor[eth0/virtio-server] ----> intermediate[assign virtio
device] ----> guest[virtio-driver]
well, it's probably still unreadable)
--
error compiling committee.c: too many arguments to function
--
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
