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

[Anthony Liguori <anthony@codemonkey.ws>]

On 07/01/2011 07:52 AM, Paul Brook wrote:
>>> 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'm not quite sure what you're getting at here.  IMO there should be little or
> no need for special knowledge of passthrough devices.  They should just be
> annother qdev device, configured in the normal way.  e.g.:
>     -device sysbus-host,hostdev=whatever,normal_mmio_and_irq_config

What I wrote about is just readconfig syntax.  It's the same as:

-device physical-device,id=mydev,region[0].file=/dev/mem,....

Regards,

Anthony Liguori

>> 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.
>
> I aggree.  Any sort of device tree (IIUC ACPI tables are in principle giving
> the same information) is, in practice, going to need to be assembled at
> runtime.  This needs some mechanism for devices to describe themselves,
> probably largely independent of actual machine/device creation code.
>
> We've got away without it thus far because the only real place where we have
> nontrivial user-specified machine variants is on the PCI bus.  Devices there
> are for the most part self-describing so the guest firmware/OS can probe
> hardware itself.
>
> Paul
>