Re: [RFC PATCH 0/3] generic hypercall support

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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

[Index of Archives]     [KVM ARM]     [KVM ia64]     [KVM ppc]     [Virtualization Tools]     [Spice Development]     [Libvirt]     [Libvirt Users]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite Questions]     [Linux Kernel]     [Linux SCSI]     [XFree86]
  Powered by Linux