Laine Stump <la...@redhat.com> writes: > For a long time, libvirt assumed by default that all types of virtual > machines had an integrated IDE controller named "ide" that wasn't > specified on the qemu commandline. Since that caused problems > specifically for the Q35 machine type (which has an *ahci* controller > that it perplexingly calls "ide"), I added code to libvirt to only > make that assumption for i440fx-based machinetypes, and to log an > error and fail in all other cases where someone tried to create a disk > attached to an IDE controller: > > http://libvirt.org/git/?p=libvirt.git;a=commitdiff;h=eadd757 > > (libvirt doesn't support explicitly adding IDE controllers on the qemu > commandline, under the assumption that 1) there are lots of better > ways to attach a disk and 2) nobody has asked for it up to now, and we > don't want to encourage them to start using something that is slow and > unnecessary). > > But I just received an email from someone who informed me that the > "ppc-beigeg3" machine type also has an IDE controller, and that > additionally this is the *only* method of connecting a disk on this > particular machine. So now I'm wondering how I can determine what > other machinetypes have an integrated IDE controller, so that I can > add them to this check. (I would also like to find out which qemu > binary supports the "ppc-beigeg3" machinetype - I tried running > "qemu-blah -M ?" for every qemu binary on my Fedora 22 system, and > didn't see anything like that).
Basically, your problem is to find the plugs provided by the board, for each machine type. I figure the sane way to find them is QOM introspection: walk the QOM tree and collect the plugs. Beware, I'm only superficially familiar with QOM, so my explanations may be off. Cc'ing Andreas, who can hopefully correct my mistakes. The relevant QMP commands are qom-list and qom-get. But to explore the QOM tree, I rather like "info qom-tree" (sadly, still HMP only) and scripts/qmp/qom-fuse (which uses qom-list and qom-get under the hood). Start QEMU with an HMP monitor on stdio and a QMP monitor on /wherever/qmp-socket, and run "info qom-tree": $ qemu-system-x86_64 -nodefaults -S -display none -monitor stdio -chardev id=chr-qmp,backend=socket,path=test-qmp,server,nowait -mon mode=control,id=mon-qmp,chardev=chr-qmp QEMU 2.4.50 monitor - type 'help' for more information (qemu) info qom-tree /machine (pc-i440fx-2.5-machine) /unattached (container) [...] /device[16] (piix3-ide) /bus master[0] (qemu:memory-region) /piix-bmdma-container[0] (qemu:memory-region) /piix-bmdma[0] (qemu:memory-region) /bmdma[0] (qemu:memory-region) /piix-bmdma[1] (qemu:memory-region) /bmdma[1] (qemu:memory-region) /ide.0 (IDE) /ide.1 (IDE) [...] In another terminal, run $ QMP_SOCKET=/wherever/qmp-socket scripts/qmp/qom-fuse /mount/point $ cd /mount/point Now let's explore a bit. $ cd machine/unattached/device\[16\] $ ls -F addr hotpluggable multifunction realized bmdma[0]/ hotplugged parent_bus@ rombar bmdma[1]/ ide.0/ piix-bmdma-container[0]/ romfile bus master[0]/ ide.1/ piix-bmdma[0]/ type command_serr_enable legacy-addr piix-bmdma[1]/ $ cat type piix3-ide This is the device model. $ ls -l parent_bus lrwxr-xr-x. 2 armbru armbru 4096 Jan 1 1970 parent_bus -> ../../../machine/i440fx/pci.0 This is the bus it's plugged in, and its name is "pci.0". $ cat parent_bus/type PCI It's a PCI bus (surprise, surprise). $ cat addr 9 Our piix3-ide's PCI address 01.1 (encoded as decimal integer). $ ls -F ide.0 hotplug-handler@ realized type $ cat ide.0/type IDE Aha, this is a bus, the bus type is IDE, and its name is "ide.0". When you're done, don't forget to kill qom-fuse. Hope this helps!