Bug 1212317

Some questions / notes:

(1) What justifies Severity=high?

    As far as I understand, we need the floppy drive for very old Windows
    releases (ie. pre-Windows 7), because that's the only way they can
    install the virtio-win drivers. However, Windows 7 and later can use two
    CD-ROMs during install (two IDE CD-ROMs, or one IDE plus one
    virtio-scsi), where the IDE one holds the virtio-win ISO, and the other
    one (virtio-scsi or IDE) holds the windows installer ISO.

(2) Does the exact same command line produce a working floppy drive with
    SeaBIOS + Windows 8?

(3) Hmmm, okay, I added a floppy drive (using virt-manager) to my existing
    OVMF windows 8 guest. I downloaded an empty, 1.44MB disk image from
    <http://www.rmprepusb.com/tutorials/winimage>, called
    BLANK_FLOPPY144.IMA, and attached it to the drive in virt-manager.

    OVMF itself (in the UEFI shell) recognizes the floppy disk.

    In the File Explorer window, Windows 8 does not show the floppy.
    However, I then went to Device Manager, and it *does* list

    Floppy drive controllers
      Standard floppy disk controller

    and under Properties it says "this device is working correctly".

I don't know how to debug this further, especially because OVMF itself sees
the disk. Debugging Windows 8 seems to be necessary to me, and I don't know
anything about Windows.

(In reply to Laszlo Ersek from comment #2)
> Some questions / notes:
> 

Setting NEEDINFO(Mike)


> (1) What justifies Severity=high?
> 
>     As far as I understand, we need the floppy drive for very old Windows
>     releases (ie. pre-Windows 7), because that's the only way they can
>     install the virtio-win drivers. However, Windows 7 and later can use two
>     CD-ROMs during install (two IDE CD-ROMs, or one IDE plus one
>     virtio-scsi), where the IDE one holds the virtio-win ISO, and the other
>     one (virtio-scsi or IDE) holds the windows installer ISO.

Agree, changing it to low (feel free to change it back to high or medium if you have a reason to do so).

> 
> (2) Does the exact same command line produce a working floppy drive with
>     SeaBIOS + Windows 8?
> 

This is an important question for further triage.

(In reply to Laszlo Ersek from comment #2)
> Some questions / notes:
> 
> (1) What justifies Severity=high?
> 
>     As far as I understand, we need the floppy drive for very old Windows
>     releases (ie. pre-Windows 7), because that's the only way they can
>     install the virtio-win drivers. However, Windows 7 and later can use two
>     CD-ROMs during install (two IDE CD-ROMs, or one IDE plus one
>     virtio-scsi), where the IDE one holds the virtio-win ISO, and the other
>     one (virtio-scsi or IDE) holds the windows installer ISO.

AFAIK ,qemu-kvm-rhev is used for RHEV and RHOS. RHEVM only support 1 emulated cdrom currently(My information may out of date ..).
> 
> (2) Does the exact same command line produce a working floppy drive with
>     SeaBIOS + Windows 8?

yes ,exactly.
> 
> (3) Hmmm, okay, I added a floppy drive (using virt-manager) to my existing
>     OVMF windows 8 guest. I downloaded an empty, 1.44MB disk image from
>     <http://www.rmprepusb.com/tutorials/winimage>, called
>     BLANK_FLOPPY144.IMA, and attached it to the drive in virt-manager.
> 
>     OVMF itself (in the UEFI shell) recognizes the floppy disk.
> 
>     In the File Explorer window, Windows 8 does not show the floppy.
>     However, I then went to Device Manager, and it *does* list
> 
>     Floppy drive controllers
>       Standard floppy disk controller
> 
>     and under Properties it says "this device is working correctly".

Right , That is exactly what I hit .
What's more ,I add windows unattened installation config file(like the kickstart for linux) in the floppy ,the file can not be read during guest installation as well.
> 
> I don't know how to debug this further, especially because OVMF itself sees
> the disk. Debugging Windows 8 seems to be necessary to me, and I don't know
> anything about Windows.

This Microsoft technet discussion seems relevant:

https://social.technet.microsoft.com/Forums/windows/en-US/f17db175-d146-4518-b2e9-c12a15031222/legacy-floppy-compatibility-with-uefi-boot

In it people originally suggested that the windows *UEFI* bootloader deliberately instructed the windows kernel to hide / ignore floppy drives (not the controller, just the drives). However, in the last message, a commenter stated that implementing the _FDE ACPI method for the FDC (controller) ACPI object allowed windows to recognize the drive.

I just checked the ACPI specification (v6.0) and indeed _FDE (Floppy Disk Enumerate) appears a method whose absence could prevent an OS from enumerating floppy disks.

The commenter said the disk appeared unformatted (incorrectly). I'm thinking that that in turn was due to _FDI (Floppy Disk Information) missing.

QEMU doesn't seem to provide either _FDE or _FDI. I'm not sure why Windows demands these methods only from a UEFI firmware (and not from BIOS), but this explanation looks plausible to me.

See also:

https://social.technet.microsoft.com/Forums/windows/en-US/e91ec27b-0c2d-44a3-b949-e77fa810a4c0/windows-7-uefi-fdd-how-to

"The final answer is that Microsoft has elected to not support FDD when booting UEFI and there is nothing you can do about it except to go back to legacy BIOS."

So, I think this bug is a CANTFIX.

Mike, what do you think? Can we perhaps get confirmation from Microsoft?

(or, well, for OVMF: NOTABUG)

Based on the information available, I'm closing this as NOTABUG.

(In reply to Laszlo Ersek from comment #7)
> "The final answer is that Microsoft has elected to not support FDD when
> booting UEFI and there is nothing you can do about it except to go back to
> legacy BIOS."
> 
> So, I think this bug is a CANTFIX.
> 
> Mike, what do you think? Can we perhaps get confirmation from Microsoft?

It is good from my side ,I just want to confirm whether it is a bug or not :)

Reopening and moving to qemu-kvm-rhev because *apparently* the discussion I quoted in comment 5 was the correct one, instead of the other discussion I quoted in comment 7.

Refer to the upstream QEMU patch series at:
http://lists.nongnu.org/archive/html/qemu-devel/2015-12/msg02073.html

(
Obviously, it remains unfathomable to me how someone can gather evidence for a statement like

> Windows [...] requests this information from BIOS via int 0x13/0x08 or
> through ACPI objects _FDE (Floppy Drive Enumerate) and _FDI (Floppy Drive
> Information).  On UEFI systems only ACPI-based detection is supported.

without reverse engineering Windows.
)

should be fixed in 2.6,
I'll add commit IDs once patches merged upstream.

Fixed upstream in QEMU-2.6, relevant commits:

27b9fc5 i386: populate floppy drive information in DSDT
e08fde0 fdc: add function to determine drive chs limits
bda0550 i386: expose floppy drive CMOS type
9b613f4 i386/acpi: make floppy controller object dynamic

This bug was accidentally moved from POST to MODIFIED via an error in automation, please see mmccune with any questions

Reproduced the bz on host-kernel-3.10.0-327.8.1.el7.x86_64 and qemu-kvm-rhev-debuginfo-2.3.0-31.el7_2.21.x86_64, OVMF-20150414-2.gitc9e5618.el7.noarch.

Verified the bz on qemu-kvm-rhev-2.6.0-20.el7.x86_64, host-kernel-3.10.0-492.el7.x86_64 and OVMF-20150414-2.gitc9e5618.el7.noarch

qemu command line:
/usr/libexec/qemu-kvm \
-M pc \
-cpu SandyBridge \
-nodefaults -rtc base=utc \
-m 4G \
-smp 2,sockets=2,cores=1,threads=1 \
-enable-kvm \
-uuid 990ea161-6b67-47b2-b803-19fb01d30d12 \
-k en-us \
-nodefaults \
-drive file=/usr/share/OVMF/OVMF_CODE.fd,if=pflash,format=raw,unit=0,readonly=on \
-drive file=/home/OVMF_VARS.fd,if=pflash,format=raw,unit=1 \
-serial unix:/tmp/serial0,server,nowait \
-debugcon file:/home/ovmf.log \
-global isa-debugcon.iobase=0x402 \
-boot menu=on \
-qmp tcp:0:6666,server,nowait \
-vga qxl \
-spice port=5932,disable-ticketing \
-drive file=/home/bug/win8.64.qcow2,if=none,id=drive-virtio-disk0,format=qcow2,cache=none,werror=stop,rerror=stop \
-device virtio-blk-pci,drive=drive-virtio-disk0,id=virtio-disk0 \
-device virtio-net-pci,netdev=tap10,mac=9a:6a:6b:6c:6d:6e -netdev tap,id=tap10 \
-drive file=/home/virtio-win.iso,if=none,media=cdrom,id=drive-ide1,format=raw \
-device ide-drive,bus=ide.0,unit=0,drive=drive-ide1,id=ide1 \
-cdrom /home/en_windows_8_enterprise_x64_dvd_917522.iso \
-drive file=/home/floppy1.vfd,if=none,id=drive-fdc0-0-0,format=raw,cache=none \
-global isa-fdc.driveA=drive-fdc0-0-0 \
-monitor stdio \

Thanks
Jing Zhao

Move to verified according to comment 16

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/RHBA-2016-2673.html