[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] device assignment for embedded Power
From: |
Paul Brook |
Subject: |
Re: [Qemu-devel] device assignment for embedded Power |
Date: |
Fri, 1 Jul 2011 13:52:37 +0100 |
User-agent: |
KMail/1.13.7 (Linux/2.6.39-2-amd64; KDE/4.6.3; x86_64; ; ) |
> > 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
Should work the same as adding any other device. If it doesn't then we should
fix that. This is an example of why it's good to have device features (IRQs,
MMIO regions, sockets, or whatever we call them) registered when the device is
instantiated, not relying on pre-compiled device decriptors/property lists.
In the latter case you probably need explicit variants for differnt numbers of
IRQs, MMIO regions, etc.
While I'm thinking about it, we already have exactly this for USB (i.e. the
usb-host device).
> 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
- Re: [Qemu-devel] device assignment for embedded Power, Alexander Graf, 2011/07/01
- Re: [Qemu-devel] device assignment for embedded Power, Anthony Liguori, 2011/07/01
- Re: [Qemu-devel] device assignment for embedded Power,
Paul Brook <=
- Re: [Qemu-devel] device assignment for embedded Power, Scott Wood, 2011/07/01
- Re: [Qemu-devel] device assignment for embedded Power, Paul Brook, 2011/07/01
- Re: [Qemu-devel] device assignment for embedded Power, Scott Wood, 2011/07/01
- Re: [Qemu-devel] device assignment for embedded Power, Paul Brook, 2011/07/01
- Re: [Qemu-devel] device assignment for embedded Power, Scott Wood, 2011/07/01
- Re: [Qemu-devel] device assignment for embedded Power, Paul Brook, 2011/07/01
- Re: [Qemu-devel] device assignment for embedded Power, Benjamin Herrenschmidt, 2011/07/01
- Re: [Qemu-devel] device assignment for embedded Power, Paul Brook, 2011/07/01
- Re: [Qemu-devel] device assignment for embedded Power, Alexander Graf, 2011/07/01