qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH 0/8] Add virtio-mmio and use it in vexpress


From: Christoffer Dall
Subject: Re: [Qemu-devel] [PATCH 0/8] Add virtio-mmio and use it in vexpress
Date: Wed, 17 Jul 2013 10:30:26 +0100
User-agent: Mutt/1.5.21 (2010-09-15)

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 <address@hidden> 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 via email to

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