From: Anthony Liguori <aliguori@us.ibm.com>
To: Peter Maydell <peter.maydell@linaro.org>, Alexander Graf <agraf@suse.de>
Cc: KONRAD Frederic <fred.konrad@greensocs.com>,
David Gibson <david@gibson.dropbear.id.au>,
kvmarm@lists.cs.columbia.edu, qemu-devel@nongnu.org,
patches@linaro.org
Subject: Re: [Qemu-devel] [PATCH 0/8] Add virtio-mmio and use it in vexpress
Date: Mon, 08 Jul 2013 15:08:56 -0500 [thread overview]
Message-ID: <87li5gbyqv.fsf@codemonkey.ws> (raw)
In-Reply-To: <CAFEAcA8C9Q5nt1RR8c6tC=00vcLtrjFZSWVTR-ebv4LzdG5hQA@mail.gmail.com>
Peter Maydell <peter.maydell@linaro.org> writes:
> On 8 July 2013 14:45, Alexander Graf <agraf@suse.de> wrote:
>> On 08.07.2013, at 15:23, Peter Maydell wrote:
>>> Now I'm completely confused. Why would assigned devices
>>> have anything to do with this? Can you explain in more
>>> detail, because I don't really see what you're suggesting?
>>
>> The only missing link we have to create any device using -device
>> on the command line is the IRQ line enumeration. If we can allocate
>> IRQ lines automatically, we can put any command line given -device
>> onto our main system bus that is non-pci, non-isa.
>
> If the user is expected to be able to get the MMIO address
> right (which they'd have to specify on the command line
> somehow too) why not require them to specify the IRQ number
> while they're doing it? I'm a bit suspicious of anything
> that requires the user to specify to that level of detail
> though, since it requires a lot of inside knowledge about the
> board.
>
> This is the whole reason for having the separate transport:
> the board gets to take care of the board specific detail of
> how to wire up the transport, and the user just asks to
> create the backends that plug automatically into it.
> The virtio command line options are complicated and confusing
> enough as it is.
>
>> So if we want to ever support VFIO for platform devices,
>> the user will want to pass -device vfio-ahci,foo=bar on
>> the command line to assign an AHCI device.
>
> This appears to be seriously short on actually specifying
> enough information to wire a device up.
>
>> The only infrastructure blocker we have for that today
>> is the IRQ allocation.
>
> DMA lines? Specifying the right location in the address space?
>
>> Maybe we could even try to be as smart as putting the MMIO
>> regions into guest address space intelligently automatically.
>
> This sounds likely to cause problems with migration unless
> we can guarantee that we always pick the same place.
I think we're trying to fit a square peg into a round hole.
virtio-mmio is a virtio transport where each device has a dedicated set
of system resources.
Alex, it sounds like you want virtio-mmio-bus which would be a single
set of system resources that implemented a virtio bus on top of it.
Regards,
Anthony Liguori
>
> -- PMM
next prev parent reply other threads:[~2013-07-08 20:13 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-06-27 13:04 [Qemu-devel] [PATCH 0/8] Add virtio-mmio and use it in vexpress Peter Maydell
2013-06-27 13:04 ` [Qemu-devel] [PATCH 1/8] device_tree: Add qemu_devtree_setprop_sized_cells() utility functions Peter Maydell
2013-06-27 13:04 ` [Qemu-devel] [PATCH 2/8] arm/boot: Use qemu_devtree_setprop_sized_cells() Peter Maydell
2013-06-27 13:04 ` [Qemu-devel] [PATCH 3/8] virtio: Add support for guest setting of queue size Peter Maydell
2013-07-08 19:39 ` Anthony Liguori
2013-07-09 8:27 ` Peter Maydell
2013-06-27 13:04 ` [Qemu-devel] [PATCH 4/8] virtio: Support transports which can specify the vring alignment Peter Maydell
2013-06-27 13:04 ` [Qemu-devel] [PATCH 5/8] virtio: Implement MMIO based virtio transport Peter Maydell
2013-07-08 19:52 ` Anthony Liguori
2013-06-27 13:04 ` [Qemu-devel] [PATCH 6/8] arm/boot: Allow boards to modify the FDT blob Peter Maydell
2013-06-27 13:04 ` [Qemu-devel] [PATCH 7/8] vexpress: Make VEDBoardInfo extend arm_boot_info Peter Maydell
2013-06-27 13:04 ` [Qemu-devel] [PATCH 8/8] vexpress: Add virtio-mmio transports Peter Maydell
2013-07-08 12:57 ` [Qemu-devel] [PATCH 0/8] Add virtio-mmio and use it in vexpress Alexander Graf
2013-07-08 12:59 ` Alexander Graf
2013-07-08 13:08 ` Peter Maydell
2013-07-08 13:16 ` Alexander Graf
2013-07-08 13:23 ` Peter Maydell
2013-07-08 13:45 ` Alexander Graf
2013-07-08 14:06 ` Peter Maydell
2013-07-08 20:08 ` Anthony Liguori [this message]
2013-07-08 20:47 ` Alexander Graf
2013-07-08 21:06 ` Anthony Liguori
2013-07-09 9:28 ` Andreas Färber
2013-07-10 10:56 ` Alexander Graf
2013-07-17 9:30 ` Christoffer Dall
2013-07-17 9:34 ` Peter Maydell
2013-07-17 12:41 ` Anthony Liguori
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=87li5gbyqv.fsf@codemonkey.ws \
--to=aliguori@us.ibm.com \
--cc=agraf@suse.de \
--cc=david@gibson.dropbear.id.au \
--cc=fred.konrad@greensocs.com \
--cc=kvmarm@lists.cs.columbia.edu \
--cc=patches@linaro.org \
--cc=peter.maydell@linaro.org \
--cc=qemu-devel@nongnu.org \
/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.