qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Christoffer Dall <christoffer.dall@linaro.org>
To: Alexander Graf <agraf@suse.de>
Cc: Anthony Liguori <aliguori@us.ibm.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: Wed, 17 Jul 2013 10:30:26 +0100	[thread overview]
Message-ID: <20130717093026.GD49546@lvm> (raw)
In-Reply-To: <A967E666-D071-4CE9-84EA-638E3CA85E53@suse.de>

On Wed, Jul 10, 2013 at 12:56:31PM +0200, Alexander Graf wrote:
> 
> On 08.07.2013, at 23:06, Anthony Liguori wrote:
> 
> > Alexander Graf <agraf@suse.de> writes:
> > 
> >> On 08.07.2013, at 22:08, Anthony Liguori wrote:
> >> 
> >>> 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.
> >> 
> >> Well, what I really want is a sysbus that behaves like PCI from a
> >> usability point of view ;).
> > 
> > Which means you need to have (1) a discovery mechanism with a stable
> > addressing mechanism
> 
> That's what dtb usually gives you.
> 
> > (2) a way to communicate this to the guest from the
> > host.
> 
> Not if the host dictates everything. PCI is only complicated because it allows the guest control. If we don't we can have a push-only interface.
> 
> But I'm not sure we should hold back this patch series based on this. I can try to come up with a bus that can automatically place memory regions and IRQs. Then I can add a virtio-mmio-awesomebus type and show you what I mean ;)
> 
> For the time being, we can live with a few statically allocated virtio transports I think. As long as we don't promise the user that they're still going to be there in the next version of QEMU.
> 
> 
I'm not familiar enough with QEMU internals to intelligently comment on
this discussion, but I do have two observations:

(1) It would be tremendously beneficial to have this patch series
merged, so people can actually start to have upstream code that supports
usable VMs on ARM, and it doesn't seem too invasive to me.

(2) About device assignment, what is the QEMU vision in terms of how it
plugs into a board?  Do we expect a mach-virt scenario where we
dynamically create assigned devices, or would we emulate some board that
actually has the peripherals that we are going to assign and emulate the
rest of the devices?

-Christoffer

  reply	other threads:[~2013-07-17  9:26 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
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 [this message]
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=20130717093026.GD49546@lvm \
    --to=christoffer.dall@linaro.org \
    --cc=agraf@suse.de \
    --cc=aliguori@us.ibm.com \
    --cc=david@gibson.dropbear.id.au \
    --cc=kvmarm@lists.cs.columbia.edu \
    --cc=patches@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).