On Thursday 25 December 2008 19:07:22 Avi Kivity wrote:
> Sheng Yang wrote:
> > For MSI-X, we have to deal with multiply IRQ with same IRQ handler, so
> > it's necessary to record the IRQ that trigger the IRQ handler.
>
> Does MSI-X disallowing coalescing two requests into one interrupt? Or
> can we still coalesce interrupts (perhaps by recording them as a (irq,
> cpu) pair?)
Disallow? Not quite understand. PCI spec said OS don't need to ensure the
sequence they handled is the same as they happened. This struct is used just
because we lost information of irq after schedule_work...
> > @@ -313,6 +314,9 @@ struct kvm_assigned_dev_kernel {
> > int host_irq;
> > bool host_irq_disabled;
> > int guest_irq;
> > +#define KVM_ASSIGNED_DEV_IRQ_FIFO_LEN 0x100
> > + struct kfifo *irq_fifo;
> > + spinlock_t irq_fifo_lock;
> > #define KVM_ASSIGNED_DEV_GUEST_INTX (1 << 0)
>
> What if it runs out?
>
> What does real hardware do? I'm sure it doesn't have a 100-entry queue.
0x100 is just a simple number which I thought different interrupts of same
MSI-X device can happen at same period(indeed it's 0x100/sizeof(int)). Maybe
not that many. And it just used by work function later to find what guest
vector is, and then inject the correlated interrupt to the guest.
If hardware device driver also postpone the work, I think it also need
something like this.
--
regards
Yang, Sheng
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
