Re: [Qemu-devel] [PATCH] sysbus: add no_user for devices using mmio or IRQ or GPIO
Peter Maydell peter.mayd...@linaro.org writes: On 5 March 2013 04:16, Paolo Bonzini pbonz...@redhat.com wrote: Il 04/03/2013 18:58, Peter Maydell ha scritto: Mass-mark these devices as no_user. There is no such thing as a 'no-user' device -- Anthony (http://lists.gnu.org/archive/html/qemu-devel/2013-01/msg00896.html) We should figure out what we might be trying to use 'no-user' for, and consistently use it that way. Or alternatively we should remove it (perhaps replacing it with other flags). Mass-marking all the sysbus devices when we don't have a consistent sane defined semantics for the flag seems like a bad idea. $ x86_64-softmmu/qemu-system-x86_64 -device xlnx,,ps7-usb (qemu) info qtree bus: main-system-bus type System dev: xlnx,ps7-usb, id maxframes = 128 irq 1 mmio /1000 bus: usb-bus.0 type usb-bus I have no idea what this means, but I'm pretty sure that no matter how I configure it, it will never work. I agree. Exhibiting something that's a suboptimal user experience doesn't count as defining consistent semantics for no_user, though :-) Can we make some progress towards something that makes more sense? First step: reasons for marking a device no_user. From a user point of view, I think there's just one: -device/device_add cannot possibly result in a working device. Coherent enough semantics for no_user, in my opinion, but I readily concede it's not particularly useful for maintaining it as infrastructure and device models evolve. For that, we need to drill down into reasons for cannot possibly work. Here are two, please add more: * Can't make required connections -device can make only one connection: to a qbus (first order approximation). Usually suffices for devices on real buses like PCI, SCSI, ... Doesn't make any useful connection on sysbus (put in quotes because it's not really a bus). Cases in between may exist: the bus connection is real enough, but the device wants additional connections. Additional connections are made by setup code that's not reachable from -device. If they're required for the device to work, then -device cannot possibly result in a working device. Worse, -device could happily claim success all the same. Are these additional connections always required? The need for additional connections depends only on the device, right? Automated static reasoning on setup code to determine the value of a makes additional connections flag feels intractable. A runtime check could be feasible, though. * Resource collision with board The device must connect to some fixed resource, but the board already connects something to it. Without no_user, this should result in an error message of sorts, which is much better than the silent breakage above. Whether the message makes any sense to the user is a different question. Unlike above, this isn't just about the device, it's about the device and the board. Right now, one no_user has to make do for all boards. Hmm. A -device can also resource-collide with another -device. But that's outside no_user's mission: -device *can* result in a working device there, just not in this particular combination. In a declarative world, we could automatically filter out devices who need resources that are never available on this board. qdev/QOM is moving away from declarative. Ideas? [and I don't think this device can be added via the monitor but not the command line counts as consistent or coherent...] no_user applies equally to -device and device_add. The command line additionally provides a number of settings the board setup code may (or may not) use, and no_user has no effect on them. Coherent enough for me. Yes, the right thing to do would be to QOMify memory regions and introduce pins, but that's a bit more than the amount of time I have now for this. ...plus it means that when we do have these things we have to go round and identify the cases where no_user was set only because we didn't have the features before. My attitude here really is yes, it's not great but it's been like this forever and we don't seem to have had a huge flood of user complaints, so better not to mess with it unless what you're doing is going to amount to some kind of cleanup. Never underestimate users' capability to suffer quietly.
Re: [Qemu-devel] [PATCH] sysbus: add no_user for devices using mmio or IRQ or GPIO
On 7 March 2013 16:48, Markus Armbruster arm...@redhat.com wrote: Can we make some progress towards something that makes more sense? First step: reasons for marking a device no_user. From a user point of view, I think there's just one: -device/device_add cannot possibly result in a working device. Coherent enough semantics for no_user, in my opinion, but I readily concede it's not particularly useful for maintaining it as infrastructure and device models evolve. Ideally it would be nice to move to a model where the error message was the device you've created has some required connections which haven't been wired up, and then for some devices you'd always get that error [until we implemented syntax for doing the wiring] and for some you'd only get it if you messed up the command line switches. For that, we need to drill down into reasons for cannot possibly work. Here are two, please add more: * Can't make required connections * Resource collision with board The device must connect to some fixed resource, but the board already connects something to it. Without no_user, this should result in an error message of sorts, which is much better than the silent breakage above. Whether the message makes any sense to the user is a different question. Do we have any concrete examples of this? I don't think devices should be making connections to resources themselves. If the only things wiring up devices are (a) the board models and (b) anything the user says on the command line, then the conflict only happens if the user says -device foo,bar=0x42 and bar 0x42 is in use; in that case the message will make sense to them. I think a third case for no-user is this device is actually an abstract base class (eg arm_gic_common), which we could deal with by checking the TypeInfo instead. Case four: we really don't expect anybody to be trying to wire this up dynamically, which would apply to things like the on-cpu peripherals for some ARM cores. There it is really just an attempt at being friendly by cutting down the length of the devices list. Speaking of friendlyness, it might be helpful if the '-devices help' list was somehow more structured than a single long list and if more devices had description text? [and I don't think this device can be added via the monitor but not the command line counts as consistent or coherent...] no_user applies equally to -device and device_add. In the codebase as it stands, it applies only to -device. I agree that we should be consistent here, which we could do by applying Christian's patch or some variation to make device_add honour no_user. (Or by removing no_user altogether :-)) -- PMM
Re: [Qemu-devel] [PATCH] sysbus: add no_user for devices using mmio or IRQ or GPIO
Peter Maydell peter.mayd...@linaro.org writes: On 7 March 2013 16:48, Markus Armbruster arm...@redhat.com wrote: Can we make some progress towards something that makes more sense? First step: reasons for marking a device no_user. From a user point of view, I think there's just one: -device/device_add cannot possibly result in a working device. Coherent enough semantics for no_user, in my opinion, but I readily concede it's not particularly useful for maintaining it as infrastructure and device models evolve. Ideally it would be nice to move to a model where the error message was the device you've created has some required connections which haven't been wired up, and then for some devices you'd always get that error [until we implemented syntax for doing the wiring] and for some you'd only get it if you messed up the command line switches. Sounds good to me. For that, we need to drill down into reasons for cannot possibly work. Here are two, please add more: * Can't make required connections * Resource collision with board The device must connect to some fixed resource, but the board already connects something to it. Without no_user, this should result in an error message of sorts, which is much better than the silent breakage above. Whether the message makes any sense to the user is a different question. Do we have any concrete examples of this? I don't think devices should be making connections to resources themselves. If the only things wiring up devices are (a) the board models and (b) anything the user says on the command line, then the conflict only happens if the user says -device foo,bar=0x42 and bar 0x42 is in use; in that case the message will make sense to them. Not exactly what you asked for, but here goes anyway: $ qemu-system-x86_64 -nodefaults -S -vnc :0 -monitor stdio -device isa-fdc,id=foo QEMU 1.4.50 monitor - type 'help' for more information (qemu) info qtree bus: main-system-bus [...] bus: isa.0 type ISA dev: isa-fdc, id foo iobase = 0x3f0 irq = 6 dma = 2 driveA = null driveB = null bootindexA = -1 bootindexB = -1 check_media_rate = on isa irq 6 dev: isa-fdc, id iobase = 0x3f0 irq = 6 dma = 2 driveA = null driveB = null bootindexA = -1 bootindexB = -1 check_media_rate = on isa irq 6 [...] $ qemu-system-x86_64 -nodefaults -S -vnc :0 -monitor stdio -device q35-pcihost Segmentation fault (core dumped) I think a third case for no-user is this device is actually an abstract base class (eg arm_gic_common), which we could deal with by checking the TypeInfo instead. Yes. Case four: we really don't expect anybody to be trying to wire this up dynamically, which would apply to things like the on-cpu peripherals for some ARM cores. There it is really just an attempt at being friendly by cutting down the length of the devices list. Yes. Case-by-case decision, I guess. Speaking of friendlyness, it might be helpful if the '-devices help' list was somehow more structured than a single long list and if more devices had description text? Oh yes. I wanted to do that, but when Anthony started to dig up qdev, I hastened to get out of the way. [and I don't think this device can be added via the monitor but not the command line counts as consistent or coherent...] no_user applies equally to -device and device_add. In the codebase as it stands, it applies only to -device. I agree that we should be consistent here, which we could do by applying Christian's patch or some variation to make device_add honour no_user. (Or by removing no_user altogether :-)) Actually, it appears to apply only to help now! git-bisect blames this one: commit 18b6dade8c0799c48f5c5e124b8c407cd5e22e96 Author: Anthony Liguori aligu...@us.ibm.com Date: Fri Dec 9 12:08:01 2011 -0600 qdev: refactor device creation to allow bus_info to be set only in class As we use class_init to set class members, DeviceInfo no longer holds this information. Signed-off-by: Anthony Liguori aligu...@us.ibm.com Review fail, testing fail :(
Re: [Qemu-devel] [PATCH] sysbus: add no_user for devices using mmio or IRQ or GPIO
On 7 March 2013 20:45, Peter Crosthwaite peter.crosthwa...@xilinx.com wrote: Case four: we really don't expect anybody to be trying to wire this up dynamically, which would apply to things like the on-cpu peripherals for some ARM cores. What ARM cores were you thinking here exactly? We are already doing dynamic machine creation of ARM systems including instantiation of individual MPCore components. I was handwaving a bit, but for instance arm_mptimer is marked as no_user. How are you doing dynamic machine creation when neither -device nor device_add support mapping sysbus mmio or wiring up gpio and irq lines? -- PMM
Re: [Qemu-devel] [PATCH] sysbus: add no_user for devices using mmio or IRQ or GPIO
Markus Armbruster arm...@redhat.com writes: Peter Maydell peter.mayd...@linaro.org writes: [and I don't think this device can be added via the monitor but not the command line counts as consistent or coherent...] no_user applies equally to -device and device_add. In the codebase as it stands, it applies only to -device. I agree that we should be consistent here, which we could do by applying Christian's patch or some variation to make device_add honour no_user. (Or by removing no_user altogether :-)) Actually, it appears to apply only to help now! git-bisect blames this one: Let's step back and try to figure out the problem we're trying to solve. What is -devices help trying to show? Devices that are valid to for a user to pass? Hint: on a PC, the only thing that's valid to add are devices that implement a certain bus type. In fact, it depends on the bus model. So if you want to make -device help prettier, we should add a filter that looks at the busses available and filters anything that isn't an instance of the appropriate bus types. Regards, Anthony Liguori
Re: [Qemu-devel] [PATCH] sysbus: add no_user for devices using mmio or IRQ or GPIO
On 8 March 2013 00:09, Anthony Liguori aligu...@us.ibm.com wrote: What is -devices help trying to show? Devices that are valid to for a user to pass? Hint: on a PC, the only thing that's valid to add are devices that implement a certain bus type. In fact, it depends on the bus model. Yeah, I think part of the problem is that we are trying to deal with the QEMU equivalent of the following two scenarios: (a) I opened up my PC and plugged in my new PCI ethernet card (b) I modified my Dreamcast to have a VGA output with the aid of a little circuit board and a soldering iron and because we're using the same UI for both, the flexibility you need for case (b) makes it hopelessly confusing for the people who are only interested in case (a). Maybe some sort of Okay, computer, I want full manual control now switch? :-) -- PMM
Re: [Qemu-devel] [PATCH] sysbus: add no_user for devices using mmio or IRQ or GPIO
Anthony Liguori aligu...@us.ibm.com writes: Markus Armbruster arm...@redhat.com writes: Peter Maydell peter.mayd...@linaro.org writes: [and I don't think this device can be added via the monitor but not the command line counts as consistent or coherent...] no_user applies equally to -device and device_add. In the codebase as it stands, it applies only to -device. I agree that we should be consistent here, which we could do by applying Christian's patch or some variation to make device_add honour no_user. (Or by removing no_user altogether :-)) Actually, it appears to apply only to help now! git-bisect blames this one: Let's step back and try to figure out the problem we're trying to solve. What is -devices help trying to show? Devices that are valid to for a user to pass? Hint: on a PC, the only thing that's valid to add are devices that implement a certain bus type. In fact, it depends on the bus model. So if you want to make -device help prettier, we should add a filter that looks at the busses available and filters anything that isn't an instance of the appropriate bus types. Necessary, but not sufficient; see the two examples I posted upstream. Both devices would pass a appropriate bus is available filter. Both devices cannot possibly work. One of them starts up fine (mayhem at guest runtime expected), the other makes qemu crash burn immediately.
Re: [Qemu-devel] [PATCH] sysbus: add no_user for devices using mmio or IRQ or GPIO
Markus Armbruster arm...@redhat.com writes: Anthony Liguori aligu...@us.ibm.com writes: Markus Armbruster arm...@redhat.com writes: Peter Maydell peter.mayd...@linaro.org writes: [and I don't think this device can be added via the monitor but not the command line counts as consistent or coherent...] no_user applies equally to -device and device_add. In the codebase as it stands, it applies only to -device. I agree that we should be consistent here, which we could do by applying Christian's patch or some variation to make device_add honour no_user. (Or by removing no_user altogether :-)) Actually, it appears to apply only to help now! git-bisect blames this one: Let's step back and try to figure out the problem we're trying to solve. What is -devices help trying to show? Devices that are valid to for a user to pass? Hint: on a PC, the only thing that's valid to add are devices that implement a certain bus type. In fact, it depends on the bus model. So if you want to make -device help prettier, we should add a filter that looks at the busses available and filters anything that isn't an instance of the appropriate bus types. Necessary, but not sufficient; see the two examples I posted upstream. Both devices would pass a appropriate bus is available filter. Both devices cannot possibly work. One of them starts up fine (mayhem at guest runtime expected), Note that what you've done with the first one is 100% representative of real hardware. ISA bus conflicts are part of the nature of ISA and why it was such an awful bus. the other makes qemu crash burn immediately. This is a modeling problem. It doesn't make sense for q35-pcihost to be a PCIDevice. It's not a PCI device. But even so, segv'ing is always a bug and we ought to prevent it from seg faulting. no_user to hide a SEGV is just using a bandaid. Regards, Anthony Liguori
Re: [Qemu-devel] [PATCH] sysbus: add no_user for devices using mmio or IRQ or GPIO
Anthony Liguori aligu...@us.ibm.com writes: Markus Armbruster arm...@redhat.com writes: Anthony Liguori aligu...@us.ibm.com writes: Markus Armbruster arm...@redhat.com writes: Peter Maydell peter.mayd...@linaro.org writes: [and I don't think this device can be added via the monitor but not the command line counts as consistent or coherent...] no_user applies equally to -device and device_add. In the codebase as it stands, it applies only to -device. I agree that we should be consistent here, which we could do by applying Christian's patch or some variation to make device_add honour no_user. (Or by removing no_user altogether :-)) Actually, it appears to apply only to help now! git-bisect blames this one: Let's step back and try to figure out the problem we're trying to solve. What is -devices help trying to show? Devices that are valid to for a user to pass? Hint: on a PC, the only thing that's valid to add are devices that implement a certain bus type. In fact, it depends on the bus model. So if you want to make -device help prettier, we should add a filter that looks at the busses available and filters anything that isn't an instance of the appropriate bus types. Necessary, but not sufficient; see the two examples I posted upstream. Both devices would pass a appropriate bus is available filter. Both devices cannot possibly work. One of them starts up fine (mayhem at guest runtime expected), Note that what you've done with the first one is 100% representative of real hardware. ISA bus conflicts are part of the nature of ISA and why it was such an awful bus. Would be nice if we could make QEMU behave less awful. the other makes qemu crash burn immediately. This is a modeling problem. It doesn't make sense for q35-pcihost to be a PCIDevice. It's not a PCI device. But even so, segv'ing is always a bug and we ought to prevent it from seg faulting. no_user to hide a SEGV is just using a bandaid. A bandaid isn't half bad when you're bleeding :)
Re: [Qemu-devel] [PATCH] sysbus: add no_user for devices using mmio or IRQ or GPIO
On Fri, Mar 8, 2013 at 1:41 AM, Peter Maydell peter.mayd...@linaro.org wrote: On 7 March 2013 20:45, Peter Crosthwaite peter.crosthwa...@xilinx.com wrote: Case four: we really don't expect anybody to be trying to wire this up dynamically, which would apply to things like the on-cpu peripherals for some ARM cores. What ARM cores were you thinking here exactly? We are already doing dynamic machine creation of ARM systems including instantiation of individual MPCore components. I was handwaving a bit, but for instance arm_mptimer is marked as no_user. How are you doing dynamic machine creation when neither -device nor device_add support mapping sysbus mmio or wiring up gpio and irq lines? Its all out of tree using out device tree driven machine instantiation but we are toying with the idea of moving away from that in favour of -device and friends (2100 less lines out of tree code for me), once the aforementioned fixes to sysbus/gpio go through. ARM MPTimer will still be one of the IPs we will want to dynamically create however. Regards, Peter -- PMM
Re: [Qemu-devel] [PATCH] sysbus: add no_user for devices using mmio or IRQ or GPIO
On 8 March 2013 07:37, Peter Crosthwaite peter.crosthwa...@xilinx.com wrote: Its all out of tree using out device tree driven machine instantiation but we are toying with the idea of moving away from that in favour of -device and friends (2100 less lines out of tree code for me), once the aforementioned fixes to sysbus/gpio go through. ARM MPTimer will still be one of the IPs we will want to dynamically create however. Yeah, I think the 'completely specify your machine from pieces' usecase is one we have in mind; it's just you can't do it today (due to the irq/mmio issues). Also as I said it's not clear that the UI/interface for that should be the same as the one for allowing the user to plug in PCI cards or disks to a model somebody else has constructed for them. -- PMM
Re: [Qemu-devel] [PATCH] sysbus: add no_user for devices using mmio or IRQ or GPIO
Il 05/03/2013 00:22, Peter Maydell ha scritto: Yes, the right thing to do would be to QOMify memory regions and introduce pins, but that's a bit more than the amount of time I have now for this. ...plus it means that when we do have these things we have to go round and identify the cases where no_user was set only because we didn't have the features before. Yes, that's why my patch includes a comment to this end. My attitude here really is yes, it's not great but it's been like this forever and we don't seem to have had a huge flood of user complaints, so better not to mess with it unless what you're doing is going to amount to some kind of cleanup. I did find a complaint from a Red Hat tester about having the sysbus EHCI device in the help. I guess an alternative fix will be to move those device to a separate CONFIG_ symbol. Paolo
Re: [Qemu-devel] [PATCH] sysbus: add no_user for devices using mmio or IRQ or GPIO
On 03/05/13 11:58, Paolo Bonzini wrote: Il 05/03/2013 00:22, Peter Maydell ha scritto: Yes, the right thing to do would be to QOMify memory regions and introduce pins, but that's a bit more than the amount of time I have now for this. ...plus it means that when we do have these things we have to go round and identify the cases where no_user was set only because we didn't have the features before. Yes, that's why my patch includes a comment to this end. My attitude here really is yes, it's not great but it's been like this forever and we don't seem to have had a huge flood of user complaints, so better not to mess with it unless what you're doing is going to amount to some kind of cleanup. I did find a complaint from a Red Hat tester about having the sysbus EHCI device in the help. I guess an alternative fix will be to move those device to a separate CONFIG_ symbol. Or just exclude any sysbus device? Or will that kill too much? cheers, Gerd
[Qemu-devel] [PATCH] sysbus: add no_user for devices using mmio or IRQ or GPIO
These features require creating the device specially from board
code. Therefore, devices that use it cannot be created with
-device. (And some of them are even visible in binaries for
qemu-system-x86_64, for example the sysbus EHCI device).
Mass-mark these devices as no_user.
Signed-off-by: Paolo Bonzini pbonz...@redhat.com
---
hw/a9scu.c | 1 +
hw/apb_pci.c | 1 +
hw/arm_sysctl.c| 1 +
hw/arm_timer.c | 2 ++
hw/armv7m.c| 1 +
hw/bitbang_i2c.c | 1 +
hw/cadence_ttc.c | 1 +
hw/cadence_uart.c | 1 +
hw/cs4231.c| 1 +
hw/ds1225y.c | 1 +
hw/eccmemctl.c | 1 +
hw/empty_slot.c| 1 +
hw/escc.c | 1 +
hw/esp.c | 1 +
hw/etraxfs_pic.c | 1 +
hw/etraxfs_ser.c | 1 +
hw/etraxfs_timer.c | 1 +
hw/exynos4210_combiner.c | 1 +
hw/exynos4210_fimd.c | 1 +
hw/exynos4210_gic.c| 2 ++
hw/exynos4210_i2c.c| 1 +
hw/exynos4210_mct.c| 1 +
hw/exynos4210_pmu.c| 1 +
hw/exynos4210_pwm.c| 1 +
hw/exynos4210_rtc.c| 1 +
hw/exynos4210_uart.c | 1 +
hw/fdc.c | 2 ++
hw/g364fb.c| 1 +
hw/ide/ahci.c | 1 +
hw/imx_avic.c | 1 +
hw/imx_ccm.c | 1 +
hw/imx_serial.c| 1 +
hw/imx_timer.c | 2 ++
hw/integratorcp.c | 1 +
hw/jazz_led.c | 1 +
hw/lan9118.c | 1 +
hw/lm32_timer.c| 1 +
hw/lm32_uart.c | 1 +
hw/marvell_88w8618_audio.c | 1 +
hw/milkymist-ac97.c| 1 +
hw/milkymist-hpdmc.c | 1 +
hw/milkymist-memcard.c | 1 +
hw/milkymist-minimac2.c| 1 +
hw/milkymist-softusb.c | 1 +
hw/mipsnet.c | 1 +
hw/mpc8544_guts.c | 1 +
hw/mst_fpga.c | 1 +
hw/musicpal.c | 8
hw/omap_gpio.c | 2 ++
hw/omap_i2c.c | 1 +
hw/omap_intc.c | 2 ++
hw/onenand.c | 1 +
hw/opencores_eth.c | 1 +
hw/openpic.c | 1 +
hw/pc_sysfw.c | 1 +
hw/pflash_cfi01.c | 1 +
hw/pflash_cfi02.c | 1 +
hw/pl011.c | 4
hw/pl022.c | 1 +
hw/pl050.c | 2 ++
hw/pl061.c | 2 ++
hw/pl080.c | 2 ++
hw/ppc/e500.c | 1 +
hw/ppce500_pci.c | 1 +
hw/ppce500_spin.c | 1 +
hw/puv3_dma.c | 2 ++
hw/puv3_gpio.c | 2 ++
hw/puv3_intc.c | 2 ++
hw/puv3_ost.c | 2 ++
hw/puv3_pm.c | 2 ++
hw/pxa2xx.c| 4
hw/pxa2xx_dma.c| 1 +
hw/pxa2xx_gpio.c | 1 +
hw/pxa2xx_pic.c| 1 +
hw/pxa2xx_timer.c | 2 ++
hw/realview_gic.c | 2 ++
hw/sdhci.c | 1 +
hw/sh_pci.c| 2 ++
hw/slavio_intctl.c | 1 +
hw/slavio_misc.c | 3 +++
hw/slavio_timer.c | 1 +
hw/smc91c111.c | 1 +
hw/sparc32_dma.c | 1 +
hw/spitz.c | 3 +++
hw/stellaris.c | 6 ++
hw/stellaris_enet.c| 1 +
hw/strongarm.c | 5 +
hw/sun4m.c | 6 ++
hw/sun4m_iommu.c | 1 +
hw/tcx.c | 1 +
hw/tusb6010.c | 1 +
hw/usb/hcd-ehci-sysbus.c | 1 +
hw/usb/hcd-ohci.c | 1 +
hw/versatile_i2c.c | 2 ++
hw/versatile_pci.c | 2 ++
hw/xgmac.c | 1 +
hw/xilinx_axidma.c | 1 +
hw/xilinx_axienet.c| 1 +
hw/xilinx_ethlite.c| 1 +
hw/xilinx_intc.c | 1 +
hw/xilinx_spi.c| 1 +
hw/xilinx_spips.c | 1 +
hw/xilinx_timer.c | 1 +
hw/xilinx_uartlite.c | 2 ++
hw/zaurus.c| 1 +
hw/zynq_slcr.c | 1 +
106 files changed, 157 insertions(+)
diff --git a/hw/a9scu.c b/hw/a9scu.c
index 0e9e54d..a3f6bfb 100644
--- a/hw/a9scu.c
+++ b/hw/a9scu.c
@@ -147,6 +147,7 @@ static void a9_scu_class_init(ObjectClass *klass, void
*data)
dc-props = a9_scu_properties;
dc-vmsd = vmstate_a9_scu;
dc-reset = a9_scu_reset;
+dc-no_user = 1; /* for sysbus mmio/irq */
}
static const TypeInfo a9_scu_info = {
diff --git a/hw/apb_pci.c b/hw/apb_pci.c
index 7eb0c2b..9198de7 100644
--- a/hw/apb_pci.c
+++ b/hw/apb_pci.c
@@ -500,6 +500,7 @@ static void pbm_host_class_init(ObjectClass *klass, void
*data)
k-init = pci_pbm_init_device;
dc-reset = pci_pbm_reset;
+dc-no_user = 1; /* for sysbus mmio/irq */
}
static const TypeInfo pbm_host_info = {
diff --git a/hw/arm_sysctl.c b/hw/arm_sysctl.c
index 7ecb7da..391709a 100644
--- a/hw/arm_sysctl.c
+++ b/hw/arm_sysctl.c
@@ -411,6 +411,7 @@ static void arm_sysctl_class_init(ObjectClass *klass, void
*data)
dc-reset = arm_sysctl_reset;
Re: [Qemu-devel] [PATCH] sysbus: add no_user for devices using mmio or IRQ or GPIO
On 5 March 2013 01:32, Paolo Bonzini pbonz...@redhat.com wrote: These features require creating the device specially from board code. Therefore, devices that use it cannot be created with -device. (And some of them are even visible in binaries for qemu-system-x86_64, for example the sysbus EHCI device). Mass-mark these devices as no_user. There is no such thing as a 'no-user' device -- Anthony (http://lists.gnu.org/archive/html/qemu-devel/2013-01/msg00896.html) We should figure out what we might be trying to use 'no-user' for, and consistently use it that way. Or alternatively we should remove it (perhaps replacing it with other flags). Mass-marking all the sysbus devices when we don't have a consistent sane defined semantics for the flag seems like a bad idea. thanks -- PMM
Re: [Qemu-devel] [PATCH] sysbus: add no_user for devices using mmio or IRQ or GPIO
Il 04/03/2013 18:58, Peter Maydell ha scritto: Mass-mark these devices as no_user. There is no such thing as a 'no-user' device -- Anthony (http://lists.gnu.org/archive/html/qemu-devel/2013-01/msg00896.html) We should figure out what we might be trying to use 'no-user' for, and consistently use it that way. Or alternatively we should remove it (perhaps replacing it with other flags). Mass-marking all the sysbus devices when we don't have a consistent sane defined semantics for the flag seems like a bad idea. $ x86_64-softmmu/qemu-system-x86_64 -device xlnx,,ps7-usb (qemu) info qtree bus: main-system-bus type System dev: xlnx,ps7-usb, id maxframes = 128 irq 1 mmio /1000 bus: usb-bus.0 type usb-bus I have no idea what this means, but I'm pretty sure that no matter how I configure it, it will never work. Yes, the right thing to do would be to QOMify memory regions and introduce pins, but that's a bit more than the amount of time I have now for this. Paolo
Re: [Qemu-devel] [PATCH] sysbus: add no_user for devices using mmio or IRQ or GPIO
On 5 March 2013 04:16, Paolo Bonzini pbonz...@redhat.com wrote: Il 04/03/2013 18:58, Peter Maydell ha scritto: Mass-mark these devices as no_user. There is no such thing as a 'no-user' device -- Anthony (http://lists.gnu.org/archive/html/qemu-devel/2013-01/msg00896.html) We should figure out what we might be trying to use 'no-user' for, and consistently use it that way. Or alternatively we should remove it (perhaps replacing it with other flags). Mass-marking all the sysbus devices when we don't have a consistent sane defined semantics for the flag seems like a bad idea. $ x86_64-softmmu/qemu-system-x86_64 -device xlnx,,ps7-usb (qemu) info qtree bus: main-system-bus type System dev: xlnx,ps7-usb, id maxframes = 128 irq 1 mmio /1000 bus: usb-bus.0 type usb-bus I have no idea what this means, but I'm pretty sure that no matter how I configure it, it will never work. I agree. Exhibiting something that's a suboptimal user experience doesn't count as defining consistent semantics for no_user, though :-) [and I don't think this device can be added via the monitor but not the command line counts as consistent or coherent...] Yes, the right thing to do would be to QOMify memory regions and introduce pins, but that's a bit more than the amount of time I have now for this. ...plus it means that when we do have these things we have to go round and identify the cases where no_user was set only because we didn't have the features before. My attitude here really is yes, it's not great but it's been like this forever and we don't seem to have had a huge flood of user complaints, so better not to mess with it unless what you're doing is going to amount to some kind of cleanup. -- PMM
