Re: [Qemu-devel] [PATCH 0/9] Add platform bus
Il 22/07/2013 20:21, Peter Maydell ha scritto: Platforms without ISA and/or PCI have had a seriously hard time in the dynamic device creation world of QEMU. Devices on these were modeled as SysBus devices which can only be instantiated in machine files, not through -device. Why is that so? Because you can't as a user of this sort of hardware plug in an extra serial port to a SoC, because there's just nowhere to plug it in. So why should it be possible to plug an extra serial port into the QEMU model of the SoC? And why exactly should QEMU be limited to modeling an existing SoC? Perhaps the user is not working with an existing SoC. They are working with with IP building blocks that they can combine the way they prefer, and they haven't yet made up their mind on the exact set of devices they'll have. (because not all the world is a PC, but then not all the non-PC world is ARM either). Perhaps the user is working on kernel support for device tree / ACPI, wants to test many device combinations, and does not want to touch C code in order to do that. Perhaps the user can plug daughterboards that connect to the SoC and add an extra serial port, visible as yet another MMIO device. And why should the user of QEMU have to know very low hardware level detail like what a particular devboard's IRQ and memory map are? Of course in some scenarios the user of QEMU doesn't need them, but there are many kinds of users... Paolo
Re: [Qemu-devel] [PATCH 0/9] Add platform bus
On 23 July 2013 13:19, Paolo Bonzini pbonz...@redhat.com wrote: Il 22/07/2013 20:21, Peter Maydell ha scritto: Platforms without ISA and/or PCI have had a seriously hard time in the dynamic device creation world of QEMU. Devices on these were modeled as SysBus devices which can only be instantiated in machine files, not through -device. Why is that so? Because you can't as a user of this sort of hardware plug in an extra serial port to a SoC, because there's just nowhere to plug it in. So why should it be possible to plug an extra serial port into the QEMU model of the SoC? And why exactly should QEMU be limited to modeling an existing SoC? Perhaps the user is not working with an existing SoC. They are working with with IP building blocks that they can combine the way they prefer, and they haven't yet made up their mind on the exact set of devices they'll have. (because not all the world is a PC, but then not all the non-PC world is ARM either). This sounds like (a) a good thing (b) something that will turn into an incredible incomprehensible mess if we try to specify it on the command line. Why would we want to do that? That is, you're arguing for a scripting/config language for putting together board models so you don't have to write them in C. That's a good thing, but not what this patch series is doing. Perhaps the user is working on kernel support for device tree / ACPI, wants to test many device combinations, and does not want to touch C code in order to do that. Perhaps the user can plug daughterboards that connect to the SoC and add an extra serial port, visible as yet another MMIO device. Pluggable daughterboards should be implemented by actually defining the bus/socket that exists between the mainboard and the daughterboard, so you could say -device my-daughterboard and have it plug in to the mainboard. -- PMM
Re: [Qemu-devel] [PATCH 0/9] Add platform bus
On 23/07/2013 14:19, Paolo Bonzini wrote: Il 22/07/2013 20:21, Peter Maydell ha scritto: Platforms without ISA and/or PCI have had a seriously hard time in the dynamic device creation world of QEMU. Devices on these were modeled as SysBus devices which can only be instantiated in machine files, not through -device. Why is that so? Because you can't as a user of this sort of hardware plug in an extra serial port to a SoC, because there's just nowhere to plug it in. So why should it be possible to plug an extra serial port into the QEMU model of the SoC? And why exactly should QEMU be limited to modeling an existing SoC? Perhaps the user is not working with an existing SoC. They are working with with IP building blocks that they can combine the way they prefer, and they haven't yet made up their mind on the exact set of devices they'll have. (because not all the world is a PC, but then not all the non-PC world is ARM either). Perhaps the user is working on kernel support for device tree / ACPI, wants to test many device combinations, and does not want to touch C code in order to do that. For what it's worth, ont sure it matters here, but the Sam460ex (PPC) (I've been writing code to support it recently) has an FDT, and a PCI controller... And there is a firmware setting to switch between the 2nd SATA port and the PCI-e slot as they are mutually exclusive... François.
Re: [Qemu-devel] [PATCH 0/9] Add platform bus
Il 23/07/2013 14:22, Peter Maydell ha scritto: On 23 July 2013 13:19, Paolo Bonzini pbonz...@redhat.com wrote: Il 22/07/2013 20:21, Peter Maydell ha scritto you can't as a user of this sort of hardware plug in an extra serial port to a SoC, because there's just nowhere to plug it in. So why should it be possible to plug an extra serial port into the QEMU model of the SoC? And why exactly should QEMU be limited to modeling an existing SoC? Perhaps the user is not working with an existing SoC. They are working with with IP building blocks that they can combine the way they prefer, and they haven't yet made up their mind on the exact set of devices they'll have. (because not all the world is a PC, but then not all the non-PC world is ARM either). This sounds like (a) a good thing (b) something that will turn into an incredible incomprehensible mess if we try to specify it on the command line. Why would we want to do that? It is an incomprehensible mess on the command line, but it is actually quite fine if you use -readconfig instead. It will not support for -serial and similar shortcut options, but they aren't necessary. PCI-enabled or paravirtual boards have been able to run for years now with -nodefaults and only -device options. That is, you're arguing for a scripting/config language for putting together board models so you don't have to write them in C. That's a good thing, but not what this patch series is doing. It is, modulo lack of support for -serial and similar shortcut options. Gluing those still requires C code (for PC as well). Perhaps the user is working on kernel support for device tree / ACPI, wants to test many device combinations, and does not want to touch C code in order to do that. Perhaps the user can plug daughterboards that connect to the SoC and add an extra serial port, visible as yet another MMIO device. Pluggable daughterboards should be implemented by actually defining the bus/socket that exists between the mainboard and the daughterboard, so you could say -device my-daughterboard and have it plug in to the mainboard. The bus might just be the processor's data bus + the interrupt controller's pins, basically the same as sysbus. In fact, the main thing I dislike about Alex's patch is adding a new bus instead of making sysbus devices just work as pluggable devices. Paolo
Re: [Qemu-devel] [PATCH 0/9] Add platform bus
On 23 July 2013 13:34, Paolo Bonzini pbonz...@redhat.com wrote: Il 23/07/2013 14:22, Peter Maydell ha scritto: On 23 July 2013 13:19, Paolo Bonzini pbonz...@redhat.com wrote: Il 22/07/2013 20:21, Peter Maydell ha scritto you can't as a user of this sort of hardware plug in an extra serial port to a SoC, because there's just nowhere to plug it in. So why should it be possible to plug an extra serial port into the QEMU model of the SoC? And why exactly should QEMU be limited to modeling an existing SoC? Perhaps the user is not working with an existing SoC. They are working with with IP building blocks that they can combine the way they prefer, and they haven't yet made up their mind on the exact set of devices they'll have. (because not all the world is a PC, but then not all the non-PC world is ARM either). This sounds like (a) a good thing (b) something that will turn into an incredible incomprehensible mess if we try to specify it on the command line. Why would we want to do that? It is an incomprehensible mess on the command line, but it is actually quite fine if you use -readconfig instead. Well, the justification for this whole new bus appears to be so you can easily just add a new device on the command line. Perhaps the user can plug daughterboards that connect to the SoC and add an extra serial port, visible as yet another MMIO device. Pluggable daughterboards should be implemented by actually defining the bus/socket that exists between the mainboard and the daughterboard, so you could say -device my-daughterboard and have it plug in to the mainboard. The bus might just be the processor's data bus + the interrupt controller's pins, basically the same as sysbus. Yes, we should have easy support for defining a pluggable bus as a collection of pins. In fact, the main thing I dislike about Alex's patch is adding a new bus instead of making sysbus devices just work as pluggable devices. Agreed, more or less. Actually I'd rather sysbus devices went away -- the requirement for interrupt and GPIO and memory regions to all be defined as single arrays (so you have to know what interrupt line 3 happens to be, and that memory region 1 is the registers, and so on) is pretty unfriendly. We should be able to define all these as named connections. -- PMM
Re: [Qemu-devel] [PATCH 0/9] Add platform bus
Il 23/07/2013 14:40, Peter Maydell ha scritto: On 23 July 2013 13:34, Paolo Bonzini pbonz...@redhat.com wrote: Il 23/07/2013 14:22, Peter Maydell ha scritto: On 23 July 2013 13:19, Paolo Bonzini pbonz...@redhat.com wrote: Il 22/07/2013 20:21, Peter Maydell ha scritto you can't as a user of this sort of hardware plug in an extra serial port to a SoC, because there's just nowhere to plug it in. So why should it be possible to plug an extra serial port into the QEMU model of the SoC? And why exactly should QEMU be limited to modeling an existing SoC? Perhaps the user is not working with an existing SoC. They are working with with IP building blocks that they can combine the way they prefer, and they haven't yet made up their mind on the exact set of devices they'll have. (because not all the world is a PC, but then not all the non-PC world is ARM either). This sounds like (a) a good thing (b) something that will turn into an incredible incomprehensible mess if we try to specify it on the command line. Why would we want to do that? It is an incomprehensible mess on the command line, but it is actually quite fine if you use -readconfig instead. Well, the justification for this whole new bus appears to be so you can easily just add a new device on the command line. -readconfig is another way to write command line options, e.g. [drive hd] file = /home/pbonzini/test.img if = none [device] driver = virtio-blk drive = hd or something like that. Perhaps the user can plug daughterboards that connect to the SoC and add an extra serial port, visible as yet another MMIO device. Pluggable daughterboards should be implemented by actually defining the bus/socket that exists between the mainboard and the daughterboard, so you could say -device my-daughterboard and have it plug in to the mainboard. The bus might just be the processor's data bus + the interrupt controller's pins, basically the same as sysbus. Yes, we should have easy support for defining a pluggable bus as a collection of pins. And a container memory region too---in the end, this is what Alex's platform bus does. In fact, the main thing I dislike about Alex's patch is adding a new bus instead of making sysbus devices just work as pluggable devices. Agreed, more or less. Actually I'd rather sysbus devices went away -- the requirement for interrupt and GPIO and memory regions to all be defined as single arrays (so you have to know what interrupt line 3 happens to be, and that memory region 1 is the registers, and so on) is pretty unfriendly. We should be able to define all these as named connections. Yeah, that's the icing on the cake. :) Paolo
Re: [Qemu-devel] [PATCH 0/9] Add platform bus
Peter Maydell peter.mayd...@linaro.org writes: On 23 July 2013 13:34, Paolo Bonzini pbonz...@redhat.com wrote: Il 23/07/2013 14:22, Peter Maydell ha scritto: On 23 July 2013 13:19, Paolo Bonzini pbonz...@redhat.com wrote: Yes, we should have easy support for defining a pluggable bus as a collection of pins. In fact, the main thing I dislike about Alex's patch is adding a new bus instead of making sysbus devices just work as pluggable devices. Agreed, more or less. Actually I'd rather sysbus devices went away -- the requirement for interrupt and GPIO and memory regions to all be defined as single arrays (so you have to know what interrupt line 3 happens to be, and that memory region 1 is the registers, and so on) is pretty unfriendly. We should be able to define all these as named connections. The concrete next steps here are well known. 1) Make MemoryRegion's QOM objects and add them as children to the devices that own them. 2) Make qemu_irq a QOM object. Then you could use -device to plumb up all of these things without SysBus being involved. But the above is a lot of work for a use-case that while interesting academically so far hasn't proven to be all that important. Regards, Anthony Liguori -- PMM
Re: [Qemu-devel] [PATCH 0/9] Add platform bus
On 23 July 2013 15:26, Anthony Liguori anth...@codemonkey.ws wrote: Peter Maydell peter.mayd...@linaro.org writes: On 23 July 2013 13:34, Paolo Bonzini pbonz...@redhat.com wrote: Il 23/07/2013 14:22, Peter Maydell ha scritto: On 23 July 2013 13:19, Paolo Bonzini pbonz...@redhat.com wrote: Yes, we should have easy support for defining a pluggable bus as a collection of pins. In fact, the main thing I dislike about Alex's patch is adding a new bus instead of making sysbus devices just work as pluggable devices. Agreed, more or less. Actually I'd rather sysbus devices went away -- the requirement for interrupt and GPIO and memory regions to all be defined as single arrays (so you have to know what interrupt line 3 happens to be, and that memory region 1 is the registers, and so on) is pretty unfriendly. We should be able to define all these as named connections. The concrete next steps here are well known. 1) Make MemoryRegion's QOM objects and add them as children to the devices that own them. 2) Make qemu_irq a QOM object. Then you could use -device to plumb up all of these things without SysBus being involved. But the above is a lot of work for a use-case that while interesting academically so far hasn't proven to be all that important. Yeah, I've generally been happy to limp along with the current sysbus stuff; I'm just saying that if we want to be able to create arbitrary MMIO devices on the command line (which is what this patchset seems to be trying to achieve) we should do it in the way you suggest above. -- PMM
[Qemu-devel] [PATCH 0/9] Add platform bus
Platforms without ISA and/or PCI have had a seriously hard time in the dynamic device creation world of QEMU. Devices on these were modeled as SysBus devices which can only be instantiated in machine files, not through -device. Why is that so? Well, SysBus is trying to be incredibly generic. It allows you to plug any interrupt sender into any other interrupt receiver. It allows you to map a device's memory regions into any other random memory region. All of that only works from C code. But do we need that level of complexity for normal devices usually? In a normal platform world (SoCs, PV machines) we have a flat memory layout we can plug our device memory into. We also have a flat IRQ model where we can plug our device IRQs into. This platform bus creates a simple bus that models the easy world. It allows for dynamic device creation through -device. A device may or may not explictly request to be mapped at a specific IRQ and/or memory address. If no explicit mapping is requested, platform devices just get mapped at convenient places. This goes hand in hand with automatic device tree generation. When QEMU places devices somewhere and also generates a device tree to tell the guest where exactly those devices are, we close the cycle and everyone knows everything and lives happily ever after. The actual pressing issue this solves is that today it's impossible to spawn serial ports from the command line. With this patch set, it's possible to do so. But it lays the groundwork for much more... Alex Alexander Graf (9): PlatBus: Add Platform Bus PlatBus: Add abstract Platform Device PlatBus: Add Sysbus/Platform bridge device PlatBus: Hook up into Makefile system PPC: Add platform bus to the default compile set PlatBus: Add serial-platbus device PPC: Add PlatBus Serial to default configs PPC: E500: Spawn PlatBus bridge for ppce500 machine PPC: E500: Add PlatBus device tree walker default-configs/ppc-softmmu.mak| 2 + default-configs/ppc64-softmmu.mak | 2 + default-configs/ppcemb-softmmu.mak | 2 + hw/Makefile.objs | 1 + hw/char/Makefile.objs | 1 + hw/char/serial-platbus.c | 100 +++ hw/platbus/Makefile.objs | 1 + hw/platbus/bridge.c| 64 +++ hw/platbus/device.c| 162 + hw/platbus/platbus.c | 107 hw/ppc/e500.c | 75 - hw/ppc/e500.h | 1 + hw/ppc/e500plat.c | 1 + include/hw/char/serial-platbus.h | 56 + include/hw/platbus/bridge.h| 32 include/hw/platbus/device.h| 102 +++ include/hw/platbus/platbus.h | 86 17 files changed, 791 insertions(+), 4 deletions(-) create mode 100644 hw/char/serial-platbus.c create mode 100644 hw/platbus/Makefile.objs create mode 100644 hw/platbus/bridge.c create mode 100644 hw/platbus/device.c create mode 100644 hw/platbus/platbus.c create mode 100644 include/hw/char/serial-platbus.h create mode 100644 include/hw/platbus/bridge.h create mode 100644 include/hw/platbus/device.h create mode 100644 include/hw/platbus/platbus.h -- 1.8.1.4
Re: [Qemu-devel] [PATCH 0/9] Add platform bus
On 22 July 2013 18:50, Alexander Graf ag...@suse.de wrote: Platforms without ISA and/or PCI have had a seriously hard time in the dynamic device creation world of QEMU. Devices on these were modeled as SysBus devices which can only be instantiated in machine files, not through -device. Why is that so? Because you can't as a user of this sort of hardware plug in an extra serial port to a SoC, because there's just nowhere to plug it in. So why should it be possible to plug an extra serial port into the QEMU model of the SoC? And why should the user of QEMU have to know very low hardware level detail like what a particular devboard's IRQ and memory map are? One thing that is missing is the ability to nicely support configuring the devices the board model creates (-global doesn't really cut it). Well, SysBus is trying to be incredibly generic. It allows you to plug any interrupt sender into any other interrupt receiver. It allows you to map a device's memory regions into any other random memory region. All of that only works from C code. But do we need that level of complexity for normal devices usually? In a normal platform world (SoCs, PV machines) we have a flat memory layout we can plug our device memory into. We also have a flat IRQ model where we can plug our device IRQs into. This platform bus creates a simple bus that models the easy world. It allows for dynamic device creation through -device. A device may or may not explictly request to be mapped at a specific IRQ and/or memory address. If no explicit mapping is requested, platform devices just get mapped at convenient places. I think this is going in the wrong direction. We should (longterm) be getting rid of sysbus in favour of having enough QOM support for a device to provide both IRQ lines and memory regions as QOM properties or links or whatever they're called. Sysbus only exists because when it was put in the qdev infrastructure implicitly assumed that everything had to be on a bus. It still exists today just because it's the easy way to declare that you have some IRQ lines and memory regions that can be wired up by the device creator. This goes hand in hand with automatic device tree generation. When QEMU places devices somewhere and also generates a device tree to tell the guest where exactly those devices are, we close the cycle and everyone knows everything and lives happily ever after. Autogenerating device trees is going to require more than this, for example where do we figure out how to specify clocks and voltage regulators for each device? (And more generally how do you handle adding whatever random extra info the kernel of the day decides it needs?) thanks -- PMM
Re: [Qemu-devel] [PATCH 0/9] Add platform bus
On 22.07.2013, at 20:21, Peter Maydell wrote: On 22 July 2013 18:50, Alexander Graf ag...@suse.de wrote: Platforms without ISA and/or PCI have had a seriously hard time in the dynamic device creation world of QEMU. Devices on these were modeled as SysBus devices which can only be instantiated in machine files, not through -device. Why is that so? Because you can't as a user of this sort of hardware plug in an extra serial port to a SoC, because there's just nowhere to plug it in. So why should it be possible to plug an extra serial port into the QEMU model of the SoC? And why should the user of QEMU have to know very low hardware level detail like what a particular devboard's IRQ and memory map are? He doesn't. That's the point. One thing that is missing is the ability to nicely support configuring the devices the board model creates (-global doesn't really cut it). Well, SysBus is trying to be incredibly generic. It allows you to plug any interrupt sender into any other interrupt receiver. It allows you to map a device's memory regions into any other random memory region. All of that only works from C code. But do we need that level of complexity for normal devices usually? In a normal platform world (SoCs, PV machines) we have a flat memory layout we can plug our device memory into. We also have a flat IRQ model where we can plug our device IRQs into. This platform bus creates a simple bus that models the easy world. It allows for dynamic device creation through -device. A device may or may not explictly request to be mapped at a specific IRQ and/or memory address. If no explicit mapping is requested, platform devices just get mapped at convenient places. I think this is going in the wrong direction. We should (longterm) be getting rid of sysbus in favour of having enough QOM support for a device to provide both IRQ lines and memory regions as QOM properties or links or whatever they're called. This is basically what this patch set does, just by trimming down the problem to a bearable set. Links become PlatBus device properties. That makes it easy to model everything. Sysbus only exists because when it was put in the qdev infrastructure implicitly assumed that everything had to be on a bus. It still exists today just because it's the easy way to declare that you have some IRQ lines and memory regions that can be wired up by the device creator. This goes hand in hand with automatic device tree generation. When QEMU places devices somewhere and also generates a device tree to tell the guest where exactly those devices are, we close the cycle and everyone knows everything and lives happily ever after. Autogenerating device trees is going to require more than this, for example where do we figure out how to specify clocks and voltage regulators for each device? (And more generally how do you handle adding whatever random extra info the kernel of the day decides it needs?) Device trees usually come from firmware. ARM is screwed up in that sense, since kernel developers randomly extend and modify device trees to their needs. So for ARM you'd also need a machine option to tell the generator which kernel flavor of the day you want to generate the device tree for. Alex
Re: [Qemu-devel] [PATCH 0/9] Add platform bus
Alexander Graf ag...@suse.de writes: Platforms without ISA and/or PCI have had a seriously hard time in the dynamic device creation world of QEMU. Devices on these were modeled as SysBus devices which can only be instantiated in machine files, not through -device. Why is that so? Well, SysBus is trying to be incredibly generic. It allows you to plug any interrupt sender into any other interrupt receiver. It allows you to map a device's memory regions into any other random memory region. All of that only works from C code. But do we need that level of complexity for normal devices usually? In a normal platform world (SoCs, PV machines) we have a flat memory layout we can plug our device memory into. We also have a flat IRQ model where we can plug our device IRQs into. This platform bus creates a simple bus that models the easy world. It allows for dynamic device creation through -device. A device may or may not explictly request to be mapped at a specific IRQ and/or memory address. If no explicit mapping is requested, platform devices just get mapped at convenient places. This goes hand in hand with automatic device tree generation. When QEMU places devices somewhere and also generates a device tree to tell the guest where exactly those devices are, we close the cycle and everyone knows everything and lives happily ever after. The actual pressing issue this solves is that today it's impossible to spawn serial ports from the command line. With this patch set, it's possible to do so. But it lays the groundwork for much more... tl;dr, this is a PV bus for the e500 described as something more generic. I don't buy it. I don't think there are many platforms or devices out there where you can arbitrarily hook up devices at random offsets/IRQs and expect things to work in any meaningful way. So I'll suggest one of three things: 1) Just use PCI and call it a day 2) Rename this to E500PlatformBus and call it a day 3) If you really want to solve the general problem of platform devices, I think the approach needs to involve: a) Forget about any bus at all, just inherit from a common base class b) Use the common base class to expose interfaces to enumerate IRQs and MemoryRegions c) Have machine-specific logic (in the post init hook) that looks for any device of the type defined in (a) and connects their IRQs/MemoryRegions as appropriate. I can believe that this approach could be reasonably generic. It's not abnormal for a hardware vendor to produce a single chip with all of the possible silicon on it and disable bits and pieces in order to offer a wider range of products. In this case, I could believe that a single SoC family could have up to four network adapters but I would also expect these adapters to live in four well known places. With a machine specific hook, you can look at the specific device type and make these types of decisions appropriately. Regards, Anthony Liguori Alex Alexander Graf (9): PlatBus: Add Platform Bus PlatBus: Add abstract Platform Device PlatBus: Add Sysbus/Platform bridge device PlatBus: Hook up into Makefile system PPC: Add platform bus to the default compile set PlatBus: Add serial-platbus device PPC: Add PlatBus Serial to default configs PPC: E500: Spawn PlatBus bridge for ppce500 machine PPC: E500: Add PlatBus device tree walker default-configs/ppc-softmmu.mak| 2 + default-configs/ppc64-softmmu.mak | 2 + default-configs/ppcemb-softmmu.mak | 2 + hw/Makefile.objs | 1 + hw/char/Makefile.objs | 1 + hw/char/serial-platbus.c | 100 +++ hw/platbus/Makefile.objs | 1 + hw/platbus/bridge.c| 64 +++ hw/platbus/device.c| 162 + hw/platbus/platbus.c | 107 hw/ppc/e500.c | 75 - hw/ppc/e500.h | 1 + hw/ppc/e500plat.c | 1 + include/hw/char/serial-platbus.h | 56 + include/hw/platbus/bridge.h| 32 include/hw/platbus/device.h| 102 +++ include/hw/platbus/platbus.h | 86 17 files changed, 791 insertions(+), 4 deletions(-) create mode 100644 hw/char/serial-platbus.c create mode 100644 hw/platbus/Makefile.objs create mode 100644 hw/platbus/bridge.c create mode 100644 hw/platbus/device.c create mode 100644 hw/platbus/platbus.c create mode 100644 include/hw/char/serial-platbus.h create mode 100644 include/hw/platbus/bridge.h create mode 100644 include/hw/platbus/device.h create mode 100644 include/hw/platbus/platbus.h -- 1.8.1.4
Re: [Qemu-devel] [PATCH 0/9] Add platform bus
On 22.07.2013, at 21:38, Anthony Liguori wrote: Alexander Graf ag...@suse.de writes: Platforms without ISA and/or PCI have had a seriously hard time in the dynamic device creation world of QEMU. Devices on these were modeled as SysBus devices which can only be instantiated in machine files, not through -device. Why is that so? Well, SysBus is trying to be incredibly generic. It allows you to plug any interrupt sender into any other interrupt receiver. It allows you to map a device's memory regions into any other random memory region. All of that only works from C code. But do we need that level of complexity for normal devices usually? In a normal platform world (SoCs, PV machines) we have a flat memory layout we can plug our device memory into. We also have a flat IRQ model where we can plug our device IRQs into. This platform bus creates a simple bus that models the easy world. It allows for dynamic device creation through -device. A device may or may not explictly request to be mapped at a specific IRQ and/or memory address. If no explicit mapping is requested, platform devices just get mapped at convenient places. This goes hand in hand with automatic device tree generation. When QEMU places devices somewhere and also generates a device tree to tell the guest where exactly those devices are, we close the cycle and everyone knows everything and lives happily ever after. The actual pressing issue this solves is that today it's impossible to spawn serial ports from the command line. With this patch set, it's possible to do so. But it lays the groundwork for much more... tl;dr, this is a PV bus for the e500 described as something more generic. I don't buy it. I don't think there are many platforms or devices out there where you can arbitrarily hook up devices at random offsets/IRQs and expect things to work in any meaningful way. So I'll suggest one of three things: 1) Just use PCI and call it a day If only the world was this easy. We already use PCI for everything where it makes sense today, but some devices I want to create dynamically from the command line simply aren't on PCI. 2) Rename this to E500PlatformBus and call it a day This could be used just the same for ARM's mach-virt, so I'd rather not make it e500 specific. 3) If you really want to solve the general problem of platform devices, I think the approach needs to involve: a) Forget about any bus at all, just inherit from a common base class b) Use the common base class to expose interfaces to enumerate IRQs and MemoryRegions c) Have machine-specific logic (in the post init hook) that looks for any device of the type defined in (a) and connects their IRQs/MemoryRegions as appropriate. Ok, I have something very similar for the device tree walker anyways, just that I'm walking a bus instead of the global device pool. But the idea is probably still the same. I suppose I'd still inherit from PlatBusDevice (which obviously would be called PlatformDevice or SimpleDevice by then) to get me my interfaces, right? I'll see what I can come up with. Alex
Re: [Qemu-devel] [PATCH 0/9] Add platform bus
Alexander Graf ag...@suse.de writes: On 22.07.2013, at 21:38, Anthony Liguori wrote: Alexander Graf ag...@suse.de writes: tl;dr, this is a PV bus for the e500 described as something more generic. I don't buy it. I don't think there are many platforms or devices out there where you can arbitrarily hook up devices at random offsets/IRQs and expect things to work in any meaningful way. So I'll suggest one of three things: 1) Just use PCI and call it a day If only the world was this easy. We already use PCI for everything where it makes sense today, but some devices I want to create dynamically from the command line simply aren't on PCI. 2) Rename this to E500PlatformBus and call it a day This could be used just the same for ARM's mach-virt, so I'd rather not make it e500 specific. If someone designed a virt machine and didn't include PCI or some other sane existing bus... It's just silly to reinvent things that already exist and are well supported by existing software/management tools. Regards, Anthony Liguori
Re: [Qemu-devel] [PATCH 0/9] Add platform bus
On 22 July 2013 20:52, Anthony Liguori anth...@codemonkey.ws wrote: Alexander Graf ag...@suse.de writes: On 22.07.2013, at 21:38, Anthony Liguori wrote: This could be used just the same for ARM's mach-virt, so I'd rather not make it e500 specific. If someone designed a virt machine and didn't include PCI or some other sane existing bus... mach-virt just means completely described by device tree with no knowledge hardcoded in the kernel about the platform. We don't currently have any PCI host controller which is: (a) for ARM (b) entirely device tree driven (c) supported by QEMU (d) with a decent Linux driver So mach-virt doesn't have PCI; it will use virtio-mmio, same as kvmtool for ARM does. -- PMM
Re: [Qemu-devel] [PATCH 0/9] Add platform bus
Peter Maydell peter.mayd...@linaro.org writes: On 22 July 2013 20:52, Anthony Liguori anth...@codemonkey.ws wrote: Alexander Graf ag...@suse.de writes: On 22.07.2013, at 21:38, Anthony Liguori wrote: This could be used just the same for ARM's mach-virt, so I'd rather not make it e500 specific. If someone designed a virt machine and didn't include PCI or some other sane existing bus... mach-virt just means completely described by device tree with no knowledge hardcoded in the kernel about the platform. Fair enough. We don't currently have any PCI host controller which is: (a) for ARM In QEMU? You can make one super easily by just extending PCIHostState. It's just a matter of mapping the index and data registers somewhere. I can't believe it's that hard to get this working in Linux either. (b) entirely device tree driven I'm not sure what this means, but presumably it wouldn't be hard to do the above. (c) supported by QEMU This part is easy enough. (d) with a decent Linux driver See above. So mach-virt doesn't have PCI; it will use virtio-mmio, same as kvmtool for ARM does. That's all well and fine but there are a lot of advantages to having PCI and being able to use all of the features associated with it. It's always tempting to reinvent the wheel when given the chance but I think in the long term, you'll regret it. Regards, Anthony Liguori -- PMM
Re: [Qemu-devel] [PATCH 0/9] Add platform bus
On 22 July 2013 23:05, Anthony Liguori anth...@codemonkey.ws wrote: Peter Maydell peter.mayd...@linaro.org writes: We don't currently have any PCI host controller which is: (a) for ARM In QEMU? You can make one super easily by just extending PCIHostState. It's just a matter of mapping the index and data registers somewhere. That's a model of some random nonexistent thing, not a model of a piece of hardware or silicon that actually exists and thus that there's some hope the kernel might someday maybe be able to drive properly. I can't believe it's that hard to get this working in Linux either. Actual ARM hardware with PCI is rare; the overlap of that with ARM hardware we model in QEMU is pretty near zero. And we demonstrably can't get the kernel folks to write working driver code for a PCI controller that only exists in QEMU -- just look at the trainwreck which is the versatile PCI kernel code. (b) entirely device tree driven I'm not sure what this means, but presumably it wouldn't be hard to do the above. It means not tied up with assumptions that the PCI controller is sitting in whatever SoC it sits in in hardware, with the clock and power control and etc etc etc that that PCI controller has in hardware. In other words, such that you can just drop a model of that controller into a random nonexistent board and have it work, rather than having to model an entire complex SoC because the driver code (entirely reasonably) assumes the hardware is always in that SoC. (c) supported by QEMU This part is easy enough. Modelling a PCI controller isn't so hard. Modelling the SoC it sits in is much harder. (d) with a decent Linux driver See above. See my remarks above too :-) So mach-virt doesn't have PCI; it will use virtio-mmio, same as kvmtool for ARM does. That's all well and fine but there are a lot of advantages to having PCI and being able to use all of the features associated with it. I completely agree. The reason we're here with virtio-mmio is because of the gaping lack of PCI for ARM yet. This will improve, I'm sure, but just now there simply isn't a sensible device we can model that I'm aware of. I'm open to suggestions if anybody has them. -- PMM
Re: [Qemu-devel] [PATCH 0/9] Add platform bus
Am 23.07.2013 00:34, schrieb Peter Maydell: On 22 July 2013 23:05, Anthony Liguori anth...@codemonkey.ws wrote: Peter Maydell peter.mayd...@linaro.org writes: We don't currently have any PCI host controller which is: (a) for ARM In QEMU? You can make one super easily by just extending PCIHostState. It's just a matter of mapping the index and data registers somewhere. That's a model of some random nonexistent thing, not a model of a piece of hardware or silicon that actually exists and thus that there's some hope the kernel might someday maybe be able to drive properly. I can't believe it's that hard to get this working in Linux either. Actual ARM hardware with PCI is rare; the overlap of that with ARM hardware we model in QEMU is pretty near zero. And we demonstrably can't get the kernel folks to write working driver code for a PCI controller that only exists in QEMU -- just look at the trainwreck which is the versatile PCI kernel code. FWIW the Nvidia Tegra3 SoC has PCIe, e.g., the Toradex Apalis T30 SoM. With the Ixora board that's coming into affordable territory for devs. Andreas -- SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg
