qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [RFC 0/4] virtio-mmio transport


From: Michael S. Tsirkin
Subject: Re: [Qemu-devel] [RFC 0/4] virtio-mmio transport
Date: Mon, 12 Dec 2011 15:12:52 +0200
User-agent: Mutt/1.5.21 (2010-09-15)

On Mon, Dec 12, 2011 at 12:28:27PM +0000, Pawel Moll wrote:
> On Mon, 2011-12-12 at 12:14 +0000, Stefan Hajnoczi wrote:
> > I noticed the virtio-mmio spec has an interrupt status register.  On
> > x86 and virtio-pci things are moving towards Message Signalled
> > Interrupts and virtqueues having their own interrupts for better
> > performance and flexibility.  Any thoughts on how 1 interrupt per
> > virtqueue works for virtio-mmio?
> 
> This could be done by either creating devices with more then one
> interrupt (platform device can take any number of resources) and
> declaring that first queue uses the first one etc.

We currently support mapping from virtqueues to interrupt
vectors in virtio core. Only virtio pci uses that
but mmio can too. It's better than fixed mapping
IMO as driver can control resources per queue.

> > My feeling is that the interrupt details are board-specific and can't
> > be described in virtio-mmio, 
> 
> It's just the the "design pattern" in the "embedded world" that devices
> usually have one interrupt output, shared between its internal
> functions. And - of course - there is no in-band signalling (like MSI)
> possible - interrupt lines are just "wires" :-) In a boundary case
> scenario we may face a situation when total amount of interrupts for all
> queues may actually exceed amount of interrupt inputs available in the
> interrupt controller...
> 
> There may be a half-way solution - one interrupt per device but the
> "active" queue number notified via the interrupt status register (as a
> FIFO) so the driver wouldn't have to enumerate all the queues.

We could use a queue for this certainly.
Why do you have so many queues?

> > but it still jumped out at me that it
> > looks like you're only thinking of 1 interrupt for the device.
> 
> Yes, current version assumes tgat. I'll keep this in mind when planning
> changes for v2 (next year ;-), thanks for letting me know!
> 
> Cheers!
> 
> PaweĊ‚
> 



reply via email to

[Prev in Thread] Current Thread [Next in Thread]