r
Hmm..you know I hadnt really thought of it that way, but you have a
point. To clarify, my design actually uses one IRQ per "eventq", where
we can have an arbitrary number of eventq's defined (note: today I only
define one eventq, however). An eventq is actually a shm-ring construct
where I can pass events up to the host like "device added" or "ring X
signaled". Each individual device based virtio-ring would then
aggregates "signal" events onto this eventq mechanism to actually inject
events to the host. Only the eventq itself injects an actual IRQ to the
assigned vcpu.
My intended use of multiple eventqs was for prioritization of different
rings. For instance, we could define 8 priority levels, each with its
own ring/irq. That way, a virtio-net that supports something like
802.1p could define 8 virtio-rings, one for each priority level.
But this scheme is more targeted at prioritization than per vcpu
irq-balancing. I support the eventq construct I proposed could still be
used in this fashion since each has its own routable IRQ. However, I
would have to think about that some more because it is beyond the design
spec.
The good news is that the decision to use the "eventq+irq" approach is
completely contained in the kvm-host+guest.patch. We could easily
switch to a 1:1 irq:shm-signal if we wanted to, and the device/drivers
would work exactly the same without modification.
Well, no, I think this part is covered. As mentioned above, we use a
queuing technique so there is no scanning needed. Ultimately I would
love to adapt a similar technique to optionally replace the LAPIC. That
way we can avoid the EOI trap and just consume the next interrupt (if
applicable) from the shm-ring.
ng
se
yeah, I agree. We can contain the "exposure" of PCI to just platforms
within KVM that care about it.
-Greg
