qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] device assignment for embedded Power


From: Anthony Liguori
Subject: Re: [Qemu-devel] device assignment for embedded Power
Date: Fri, 01 Jul 2011 07:10:45 -0500
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.17) Gecko/20110424 Lightning/1.0b2 Thunderbird/3.1.10

On 06/30/2011 07:58 PM, Benjamin Herrenschmidt wrote:
On Thu, 2011-06-30 at 15:59 +0000, Yoder Stuart-B08248 wrote:
    This avoids needing to pass the host device tree, but could
    get awkward-- the i2c example above is very simple, some device
    nodes are very large with a complex hierarchy of subnodes and
    could be hundreds of lines of text to represent a single
    node.

It gets more complicated...


So, from a qemu command line perspective, all you should have to do is
pass qemu the device-tree -path- to the device you want to pass-trough
(you may support passing a full hierarchy here).

I agree in principle but I think it should be done in a slightly different way.

I think we ought to support composing a device by passthrough. For instance, something like:

[physical-device "mydev"]
region[0].file = "/dev/mem"
region[0].guest_address = "0x42232000"
region[0].file_offset = "0x23423400"
region[0].size = "4096"
irq[0].guest_irq = "10"
irq[0].host_irq = "10"

This should be independent of anything to do with device tree. This would be useful for x86 too to assign platform devices (like the HPET).

I think there should be a separate mechanism to manipulate the guest device tree, just like there are mechanisms to manipulate the guest's ACPI tables.

Given these two mechanisms, there should be a simple command line like Ben has suggested that just takes a host device tree path and Just Works. It really is just a convenience interface though.

With raw mechanisms like I described above, it would give you the flexibility to pass through a device with a modified host tree fragment without having an overly complicated command line interface for the more common case.

Regards,

Anthony Liguori



reply via email to

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