Bug 1227880
| Summary: | update floppy command line options for QEMU's pc-q35-rhel7.2.0+ machine types | ||
|---|---|---|---|
| Product: | Red Hat Enterprise Linux 7 | Reporter: | Laszlo Ersek <lersek> |
| Component: | libvirt | Assignee: | Ján Tomko <jtomko> |
| Status: | CLOSED ERRATA | QA Contact: | Virtualization Bugs <virt-bugs> |
| Severity: | unspecified | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | 7.2 | CC: | areis, armbru, dyuan, jtomko, lmen, mzhan, rbalakri, virt-bugs, virt-maint, xuzhang, yanyang |
| Target Milestone: | rc | ||
| Target Release: | --- | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | libvirt-1.3.1-1.el7 | Doc Type: | Bug Fix |
| Doc Text: | Story Points: | --- | |
| Clone Of: | 1227282 | Environment: | |
| Last Closed: | 2016-11-03 18:18:08 UTC | Type: | Bug |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
| Bug Depends On: | 1227282 | ||
| Bug Blocks: | 1227278, 1305606, 1313485 | ||
|
Description
Laszlo Ersek
2015-06-03 17:25:03 UTC
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. 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. Pushed upstream:
commit 4edf01c92cf9004aac2a505a38d92d13050c24bc
Author: Ján Tomko <jtomko>
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 |