Re: [Qemu-devel] PCI: how handle multifunction / compound devices best?
Hi, Device macros destroy the 1:1 relationship between -device and device tree nodes. Or rather what's left of it: we already have a device that expands into multiple devices, namely usb-storage. But it's an ad hoc hack, which has caused us some grief. Exactly thats why I don't feel like adding more ad hoc hacks ... cheers, Gerd
Re: [Qemu-devel] PCI: how handle multifunction / compound devices best?
Anthony Liguori anth...@codemonkey.ws writes: On 07/01/2011 06:27 AM, Gerd Hoffmann wrote: Hi folks, I'm still looking for a sane way to handle multifunction pci devices, specifically a EHCI USB controller with UHCI companion controllers. Here comes a small (incomplete[1]) two patch series to make the issue more clear. The first patch adds a function which creates all devices with the properties set as needed. The second patch adds a '-usb2' switch to windup this in a user-friendly way. Adding a -usb2 switch sucks though. I'd prefer to have some way to create such devices via -device, but without asking the user to create all functions individually on the command line, i.e. have something along the lines of ... qemu -device ich9-usb,slot=08 This is the place where are current infrastructure pretty much stinks. The first problem is that the device factory interface should be involved with device addressing. We really should have: qemu -device ich9-usb,id=uhci0 -set i440fx.slot[8]=uhci0 The device doesn't care what it's PCI slot address is. What exactly would such a split buy us? -device is not a message to the device, it's a message to whatever makes devices. Therefore, the fact that we specify the device address with -device doesn't mean we've artificially made the device to care for its address. [...]
Re: [Qemu-devel] PCI: how handle multifunction / compound devices best?
Gerd Hoffmann kra...@redhat.com writes: Hi folks, I'm still looking for a sane way to handle multifunction pci devices, specifically a EHCI USB controller with UHCI companion controllers. Here comes a small (incomplete[1]) two patch series to make the issue more clear. The first patch adds a function which creates all devices with the properties set as needed. The second patch adds a '-usb2' switch to windup this in a user-friendly way. Adding a -usb2 switch sucks though. I'd prefer to have some way to create such devices via -device, but without asking the user to create all functions individually on the command line, i.e. have something along the lines of ... qemu -device ich9-usb,slot=08 ... instead of ... qemu \ -device ich9-usb-ehci1,addr=08.7,multifunction=on,id=ehci \ -device ich9-usb-uhci1,addr=08.0,multifunction=on,masterbus=ehci.0,firstport=0 \ -device ich9-usb-uhci2,addr=08.1,multifunction=on,masterbus=ehci.0,firstport=2 \ -device ich9-usb-uhci3,addr=08.2,multifunction=on,masterbus=ehci.0,firstport=4 Suggestions? This special case of composition is simple enough that some kind of macro expansion could work. A device defines a name, properties and a bunch of methods. A device macro could define a name, properties (the macro parameters), and an expansion. Expansions could be as simple as a list of -device where the property values can also be macro parameter names. -device MACRO,... could then be replaced by MACRO's expansion with the property values substituted. Use to make -device ich9-usb,... expand into its functions. Just an idea; I'm not claiming this is the way to go. Device macros destroy the 1:1 relationship between -device and device tree nodes. Or rather what's left of it: we already have a device that expands into multiple devices, namely usb-storage. But it's an ad hoc hack, which has caused us some grief.
Re: [Qemu-devel] PCI: how handle multifunction / compound devices best?
On 07/01/2011 06:27 AM, Gerd Hoffmann wrote: Hi folks, I'm still looking for a sane way to handle multifunction pci devices, specifically a EHCI USB controller with UHCI companion controllers. Here comes a small (incomplete[1]) two patch series to make the issue more clear. The first patch adds a function which creates all devices with the properties set as needed. The second patch adds a '-usb2' switch to windup this in a user-friendly way. Adding a -usb2 switch sucks though. I'd prefer to have some way to create such devices via -device, but without asking the user to create all functions individually on the command line, i.e. have something along the lines of ... qemu -device ich9-usb,slot=08 This is the place where are current infrastructure pretty much stinks. The first problem is that the device factory interface should be involved with device addressing. We really should have: qemu -device ich9-usb,id=uhci0 -set i440fx.slot[8]=uhci0 The device doesn't care what it's PCI slot address is. ich9-usb should be able to create its functions too as part of its initialization. I don't see an easy answer here unless we do away with the current bus model. There's no way we can do composition given the bus model we have. Best we could do is syntactic sugar for what you have below. Regards, Anthony Liguori ... instead of ... qemu \ -device ich9-usb-ehci1,addr=08.7,multifunction=on,id=ehci \ -device ich9-usb-uhci1,addr=08.0,multifunction=on,masterbus=ehci.0,firstport=0 \ -device ich9-usb-uhci2,addr=08.1,multifunction=on,masterbus=ehci.0,firstport=2 \ -device ich9-usb-uhci3,addr=08.2,multifunction=on,masterbus=ehci.0,firstport=4 Suggestions? cheers, Gerd [1] full series @ http://www.kraxel.org/cgit/qemu/log/?h=usb.18 Gerd Hoffmann (2): usb: add ich9_ehci_with_companion_init() usb: windup ich9_ehci_with_companion_init via -usb2 switch. hw/pc_piix.c| 14 ++ hw/usb-ehci.c | 49 + hw/usb.h|3 +++ qemu-options.hx | 13 +++-- vl.c|3 +++ 5 files changed, 76 insertions(+), 6 deletions(-)
