From: "Michael S. Tsirkin" <mst@redhat.com>
To: Pawel Moll <pawel.moll@arm.com>
Cc: Stefan Hajnoczi <stefanha@gmail.com>,
Anthony Liguori <aliguori@us.ibm.com>,
"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>,
Peter Maydell <peter.maydell@linaro.org>
Subject: Re: [Qemu-devel] [RFC 0/4] virtio-mmio transport
Date: Mon, 12 Dec 2011 15:12:52 +0200 [thread overview]
Message-ID: <20111212131252.GD7946@redhat.com> (raw)
In-Reply-To: <1323692907.2391.33.camel@hornet.cambridge.arm.com>
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ł
>
next prev parent reply other threads:[~2011-12-12 13:11 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-11-14 14:55 [Qemu-devel] [RFC 0/4] virtio-mmio transport Peter Maydell
2011-11-14 14:55 ` [Qemu-devel] [RFC 1/4] virtio: Add support for guest setting of queue size Peter Maydell
2011-11-14 14:55 ` [Qemu-devel] [RFC 2/4] virtio: Support transports which can specify the vring alignment Peter Maydell
2011-11-14 14:55 ` [Qemu-devel] [RFC 3/4] Add MMIO based virtio transport Peter Maydell
2011-11-14 14:55 ` [Qemu-devel] [RFC 4/4] hw/vexpress.c: Add MMIO " Peter Maydell
2011-11-14 15:41 ` [Qemu-devel] [RFC 0/4] virtio-mmio transport Stefan Hajnoczi
2011-11-16 14:33 ` Paolo Bonzini
2011-11-16 18:41 ` Peter Maydell
2011-11-16 19:56 ` Anthony Liguori
2011-11-17 11:20 ` Pawel Moll
2011-11-17 11:44 ` Paolo Bonzini
2011-12-09 15:16 ` Paul Brook
2011-12-09 15:57 ` Anthony Liguori
2011-12-12 2:52 ` Paul Brook
2011-12-12 11:16 ` Pawel Moll
2011-12-12 11:16 ` Pawel Moll
2011-12-12 14:45 ` Paul Brook
2011-12-12 14:45 ` Paul Brook
2011-12-12 14:51 ` Pawel Moll
2011-12-12 14:51 ` Pawel Moll
2011-12-16 5:36 ` Rusty Russell
2011-12-16 5:36 ` Rusty Russell
2011-12-12 12:14 ` Stefan Hajnoczi
2011-12-12 12:28 ` Pawel Moll
2011-12-12 13:12 ` Michael S. Tsirkin [this message]
2011-12-12 13:19 ` Pawel Moll
2011-12-12 15:11 ` Stefan Hajnoczi
2011-12-12 15:18 ` Peter Maydell
2011-12-12 15:21 ` Pawel Moll
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20111212131252.GD7946@redhat.com \
--to=mst@redhat.com \
--cc=aliguori@us.ibm.com \
--cc=pawel.moll@arm.com \
--cc=peter.maydell@linaro.org \
--cc=qemu-devel@nongnu.org \
--cc=stefanha@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.