Red Hat Bugzilla – Bug 1227880
update floppy command line options for QEMU's pc-q35-rhel7.2.0+ machine types
Last modified: 2016-11-03 14:18:08 EDT
Libvirt currently generates the following QEMU command line options if the VM configuration includes a floppy disk: -drive file=103RNGWIN864VYW.vfd,if=none,id=drive-fdc0-0-0,format=raw,cache=none \ -global isa-fdc.driveA=drive-fdc0-0-0 That is, libvirt relies on the board-default "isa-fdc" device (ie. frontend). It creates the backend (-drive) separately (if=none), and then binds the board-default device to the backend using the -global switch (and the appropriate properties). Starting with the upstream "pc-q35-2.4" machine type, and with the downstream "pc-q35-rhel7.2.0" machine type, this exact set of options will no longer work, because QEMU will not automatically create the isa-fdc device for them. The -drive option remains unchanged, but the -global flag should be replaced with: -device isa-fdc,driveA=drive-fdc0-0-0 (Markus, please correct me if I'm wrong.) This bug should be probably cloned for upstream libvirt too. Thanks Laszlo ------------------------- +++ This bug was initially created as a clone of Bug #1227282 +++ Rationale: http://thread.gmane.org/gmane.comp.emulators.qemu.block/2054 Upstream commits: 1 fd53c87 i386/pc: pc_basic_device_init(): delegate FDC creation request 2 936a7c1 i386/pc: '-drive if=floppy' should imply a board-default FDC 3 6cd2234 i386/pc_q35: don't insist on board FDC if there's no default floppy 4 ea96bc6 i386: drop FDC in pc-q35-2.4+ if neither it nor floppy drives are wanted --- Additional comment from Laszlo Ersek on 2015-06-03 14:41:09 CEST --- Test steps: in each invocation below, issue the "info qtree" command at the QEMU monitor prompt, and check if the "isa-fdc" device is present in the response. The common part of the commands is simply /usr/libexec/qemu-kvm -monitor stdio options isa-fdc available ------- ----------------- -M pc-i440fx-rhel7.2.0 yes -M pc-q35-rhel7.2.0 no -M pc-q35-rhel7.1.0 yes -M pc-q35-rhel7.2.0 -drive if=floppy,file=... yes
Note: piix4 machine types are not affected.
ea96bc6 i386: drop FDC in pc-q35-2.4+ if neither it nor floppy drives are wanted dropped it for older machine types too, pc_q35_2_4_machine_options is transitively called for all q35 machine types. And even with: -drive file=/var/lib/libvirt/images/floppy,if=none,id=drive-fdc0-0-0,format=raw -device isa-fdc,driveA=drive-fdc0-0-0 I can't get it to work with the pc-q35-2.4 machine type. After booting into Fedora 21 live and running: # modprobe floppy dmesg shows: [ 54.336434] FDC 0 is a S82078B but the floppy drive does not appear.
Are you sure, Ján? I can see isa-fdc in "info qtree" just fine with older q35 machine types. It's gone with the latest q35 type, and your command line snipped puts it right back. Does this guest recognize the floppy with an older QEMU?
Can you please report this bug to qemu-devel please? Please note that ea96bc6 is not how I actually implemented the patch. The way I submitted it was: http://thread.gmane.org/gmane.comp.emulators.qemu.block/2054/focus=2056 And I specifically tested (*obviously*) that it did not affect older machine types. In fact, when doing the backport for RHEL-7 -- see bug 1227282 comment 3 -- I had actually to reimplement upstream ea96bc6, and I tested that backport against old machine types too. So, the bug is present in ea96bc6, but that's actually not my code. Can you please report the issue to qemu-devel (and CC me)? Thanks.
I have sent an e-mail re: older machine types http://thread.gmane.org/gmane.comp.emulators.qemu/345202 On commit ea96bc6^ (one before the one that removed the implicit controller) and current libvirt command line the guest sees both the floppy drive and the controller. With that commit, and replacing -global with -device isa-fdc,driveA=drive-fdc0-0-0, only the controller is visible. info-qtree is identical, showing the controller in both cases: bus: isa.0 type ISA dev: isa-fdc, id "" iobase = 1008 (0x3f0) irq = 6 (0x6) dma = 2 (0x2) driveA = "drive-fdc0-0-0" driveB = "" check_media_rate = true isa irq 6 'info qom-tree' output shows the isa-fdc device moved from the /unattached (container) to the /peripheral-anon (container) after that change: --- floglo-before-ea96bc6 2015-06-18 16:51:54.128861990 +0200 +++ flofdc-after-ea96bc6 2015-06-18 16:52:38.891284278 +0200 @@ -277,36 +277,36 @@ /dma-cont[0] (qemu:memory-region) /dma-chan[1] (qemu:memory-region) /dma-page[2] (qemu:memory-region) /dma-page[3] (qemu:memory-region) /dma-cont[1] (qemu:memory-region) - /device[13] (isa-fdc) - /fdc[0] (qemu:memory-region) - /fdc[1] (qemu:memory-region) - /device[14] (ich9-ahci) + /device[13] (ich9-ahci) /bus master[0] (qemu:memory-region) /ahci[0] (qemu:memory-region) /ahci-idp[0] (qemu:memory-region) /ide.0 (IDE) /ide.1 (IDE) /ide.2 (IDE) /ide.3 (IDE) /ide.4 (IDE) /ide.5 (IDE) - /device[15] (ICH9 SMB) + /device[14] (ICH9 SMB) /bus master[0] (qemu:memory-region) /i2c (i2c-bus) /pm-smbus[0] (qemu:memory-region) + /device[15] (smbus-eeprom) /device[16] (smbus-eeprom) /device[17] (smbus-eeprom) /device[18] (smbus-eeprom) /device[19] (smbus-eeprom) /device[20] (smbus-eeprom) /device[21] (smbus-eeprom) /device[22] (smbus-eeprom) - /device[23] (smbus-eeprom) /peripheral-anon (container) + /device[0] (isa-fdc) + /fdc[0] (qemu:memory-region) + /fdc[1] (qemu:memory-region) /peripheral (container) /sata0-0-0 (ide-cd) /icc-bridge (icc-bridge) /icc (icc-bus) /icc-apic-container[0] (qemu:memory-region)
Upstream commit 473a49460db0a90bfda046b8f3662b49f94098eb should fix this. Ján, can you give it a whirl?
With that upstream commit, the floppy works fine with pc-q35-2.2. For pc-q35-2.4, -device isa-fdc is not enough to get it working. I tried adding the controller before the drive: -device isa-fdc,driveA=drive-fdc0-0-0 -drive file=/var/lib/libvirt/images/floppy,if=none,id=drive-fdc0-0-0,format=raw But the results are the same as in comment 2 - the controller is found, but fd0 does not appear.
Sigh. If you create an isa-fdc *outside* of the board init code, ie. outside of the pc_q35_init() function, then in the following call chain: pc_q35_init() pc_basic_device_init() pc_cmos_init() ... rtc_set_memory(s, 0x10, val); the value stored at 0x10 in CMOS will not reflect the floppy. This is probably what trips up a guest OS -- they look to the CMOS for seeing floppy presence. http://wiki.osdev.org/CMOS#Register_0x10 http://www.osdever.net/tutorials/view/detecting-floppy-drives In the guest kernel, "drivers/block/floppy.c" seems to be a heavy user of CMOS too. Ján, can you add the following option instead: -drive file=/var/lib/libvirt/images/floppy,if=floppy,id=drive-fdc0-0-0,format=raw This is not too nice, but (if != none) drives are already used by libvirt, for example if=pflash.
BTW I did know (and document, in fd53c87cf6651b0dfe9f5107cfe77d2f697bd4f6) that pc_cmos_init() would get NULL for "floppy" (ie. FDC) if the board-default FDC was absent. What I didn't expect was that this would prevent a guest OS from seeing an FDC (without special module parameters) that was created differently. You gotta love this rotten x86 architecture.
http://thread.gmane.org/gmane.comp.emulators.qemu.block/2685
The floopy shows up when using if=floppy, or with the following patches: http://thread.gmane.org/gmane.comp.emulators.qemu/345677 Libvirt patches adding -device isa-fdc: https://www.redhat.com/archives/libvir-list/2015-June/msg01063.html
(In reply to Ján Tomko from comment #11) > Libvirt patches adding -device isa-fdc: > https://www.redhat.com/archives/libvir-list/2015-June/msg01063.html Thanks, I'll work more on those patches, based on Markus's review.
Posted http://thread.gmane.org/gmane.comp.emulators.qemu/346297
Pushed upstream: commit 4edf01c92cf9004aac2a505a38d92d13050c24bc Author: Ján Tomko <jtomko@redhat.com> CommitDate: 2015-07-08 15:35:35 +0200 Explicitly format the isa-fdc controller for newer q35 machines Since QEMU commit ea96bc6 [1]: i386: drop FDC in pc-q35-2.4+ if neither it nor floppy drives are wanted the floppy controller is no longer implicit. Specify it explicitly on the command line if the machine type version is 2.4 or later. Note that libvirt's floppy drives do not result in QEMU implying the controller, because libvirt uses if=none instead of if=floppy. https://bugzilla.redhat.com/show_bug.cgi?id=1227880 [1] http://git.qemu.org/?p=qemu.git;a=commitdiff;h=ea96bc6 git describe: v1.2.17-42-g4edf01c
Jan, I have 2 problems and need your help. One is for machine type 'pc-q35-rhel7.2.0' why the size of floppy device mapped in guest is 1.44M, however, I created a 1G file in host, see Scenario 1, step 3 for details. Another is for machine type 'pc-q35-rhel7.1.0', -device isa-fdc,driveA=drive-fdc0-0-0 showed up in the qemu command line. I guess it is wrong, expected result should be -global isa-fdc.xxx, am I right? And I cannot find the floppy device in guest, see scenario 2 for details. libvirt-1.2.17-9.el7.x86_64 qemu-kvm-rhev-2.3.0-26.el7.x86_64 Steps Scenario 1: test machine test pc-q35-rhel7.2.0 1. define/start a vm with following xml # virsh dumpxml testvm3 <partition>/machine</partition> <type arch='x86_64' machine='pc-q35-rhel7.2.0'>hvm</type> ..... <disk type='file' device='disk'> <driver name='qemu' type='qcow2'/> <source file='/var/lib/libvirt/images/testq35.qcow2'/> <backingStore/> <target dev='vda' bus='virtio'/> <boot order='1'/> <alias name='virtio-disk0'/> <address type='pci' domain='0x0000' bus='0x02' slot='0x01' function='0x0'/> </disk> <disk type='file' device='floppy'> <driver name='qemu' type='raw'/> <source file='/var/lib/libvirt/images/floppy.img'/> <backingStore/> <target dev='fda' bus='fdc'/> <boot order='2'/> <alias name='fdc0-0-0'/> <address type='drive' controller='0' bus='0' target='0' unit='0'/> </disk> # qemu-img info /var/lib/libvirt/images/floppy.img image: /var/lib/libvirt/images/floppy.img file format: raw virtual size: 1.0G (1073741824 bytes) disk size: 0 2. # ps -ef|grep testvm3 -drive file=/var/lib/libvirt/images/floppy.img,if=none,id=drive-fdc0-0-0,format=raw -device isa-fdc,driveA=drive-fdc0-0-0,bootindexA=2 3. login guest, check floppy device # dmesg | grep -i floppy [ 10.850711] Floppy drive(s): fd0 is 1.44M =========> why the size is 1.44M # ll /dev/fd* lrwxrwxrwx. 1 root root 13 Sep 25 18:10 /dev/fd -> /proc/self/fd brw-rw----. 1 root floppy 2, 0 Sep 25 18:10 /dev/fd0 # mkfs /dev/fd0 # mount /dev/fd0 /mnt # echo hello > /mnt/hello # cat /mnt/hello hello # umount /mnt Scenario 2: test machine type pc-q35-rhel7.1.0 1. start a guest with machine type pc-q35-rhel7.1.0 # virsh dumpxml testvm3 | grep machine <type arch='x86_64' machine='pc-q35-rhel7.1.0'>hvm</type> ..... <disk type='file' device='disk'> <driver name='qemu' type='qcow2'/> <source file='/var/lib/libvirt/images/testq35.qcow2'/> <backingStore/> <target dev='vda' bus='virtio'/> <boot order='1'/> <alias name='virtio-disk0'/> <address type='pci' domain='0x0000' bus='0x02' slot='0x01' function='0x0'/> </disk> <disk type='file' device='floppy'> <driver name='qemu' type='raw'/> <source file='/var/lib/libvirt/images/floppy.img'/> <backingStore/> <target dev='fda' bus='fdc'/> <boot order='2'/> <alias name='fdc0-0-0'/> <address type='drive' controller='0' bus='0' target='0' unit='0'/> </disk> 2. check qemu command line # ps -ef|grep testvm3 /usr/libexec/qemu-kvm -name testvm3 -S -machine pc-q35-rhel7.1.0 .... -drive file=/var/lib/libvirt/images/floppy.img,if=none,id=drive-fdc0-0-0,format=raw -device isa-fdc,driveA=drive-fdc0-0-0,bootindexA=2 3. login to guest, check floppy device # dmesg | grep -i floppy NO output # ll /dev/fd0 ls: cannot access /dev/fd0: No such file or directory
1) I don't know. 2) The backport is incorrect, it matches against 'pc-q35-rhel-7.1.0' (with an extra minus between rhel and the version) instead of 'pc-q35-rhel7.1.0'. Sorry about that.
the bug is verifyed. version: libvirt-1.3.2-1.el7.x86_64 qemu-kvm-rhev-2.5.0-3.el7.x86_64 test scenarios: 1.test machine type pc-q35-rhel7.2.0 step: 1)define/start a vm with following xml # virsh dumpxml q35 ... <type arch='x86_64' machine='pc-q35-rhel7.2.0'>hvm</type> ... <disk type='file' device='disk'> <driver name='qemu' type='qcow2'/> <source file='/var/lib/libvirt/images/q35.qcow2'/> <target dev='vda' bus='virtio'/> <address type='pci' domain='0x0000' bus='0x02' slot='0x05' function='0x0'/> </disk> <disk type='file' device='floppy'> <driver name='qemu' type='raw'/> <source file='/var/lib/libvirt/images/a1.qcow2'/> <target dev='fda' bus='fdc'/> <address type='drive' controller='0' bus='0' target='0' unit='0'/> </disk> ... 2)# ps -ef | grep q35 -drive file=/var/lib/libvirt/images/a1.qcow2,format=raw,if=none,id=drive-fdc0-0-0 -device isa-fdc,driveA=drive-fdc0-0-0 3)login guest, check floppy device # dmesg | grep -i floppy [5.562818] Floppy drive(s): fd0 is 1.44M # ll /dev/fd* lrwxrwxrwx. 1 root root 13 Mar 31 13:43 /dev/fd -> /proc/self/fd brw-rw----. 1 root disk 2, 0 Mar 31 13:43 /dev/fd0 # mkfs /dev/fd0 # mount /dev/fd0 /mnt # echo hello > /mnt/hello # cat /mnt/hello hello # umount /mnt 2.test machine type pc-q35-rhel7.1.0 step: 1)define/start a vm with following xml # virsh dumpxml q35 ... <type arch='x86_64' machine='pc-q35-rhel7.1.0'>hvm</type> ... <disk type='file' device='disk'> <driver name='qemu' type='qcow2'/> <source file='/var/lib/libvirt/images/q35.qcow2'/> <target dev='vda' bus='virtio'/> <address type='pci' domain='0x0000' bus='0x02' slot='0x05' function='0x0'/> </disk> <disk type='file' device='floppy'> <driver name='qemu' type='raw'/> <source file='/var/lib/libvirt/images/a1.qcow2'/> <target dev='fda' bus='fdc'/> <address type='drive' controller='0' bus='0' target='0' unit='0'/> </disk> ... 2)# ps -ef | grep q35 -drive file=/var/lib/libvirt/images/a1.qcow2,format=raw,if=none,id=drive-fdc0-0-0 -global isa-fdc.driveA=drive-fdc0-0-0 3)login guest, check floppy device # dmesg | grep -i floppy [5.542233] Floppy drive(s): fd0 is 1.44M # ll /dev/fd* lrwxrwxrwx. 1 root root 13 Mar 31 13:49 /dev/fd -> /proc/self/fd brw-rw----. 1 root disk 2, 0 Mar 31 13:50 /dev/fd0 # mkfs /dev/fd0 # mount /dev/fd0 /mnt # echo hello > /mnt/hello # cat /mnt/hello hello # umount /mnt
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://rhn.redhat.com/errata/RHSA-2016-2577.html