[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-block] [Qemu-devel] [PATCH v5 0/6] i386: expose floppy-related
Re: [Qemu-block] [Qemu-devel] [PATCH v5 0/6] i386: expose floppy-related objects in SSDT
Wed, 13 Jan 2016 17:23:34 +0100
Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1
On 01/13/16 16:49, Roman Kagan wrote:
> On Wed, Jan 13, 2016 at 03:36:18PM +0100, Laszlo Ersek wrote:
>> On 12/30/15 21:11, Roman Kagan wrote:
>>> Windows on UEFI systems is only capable of detecting the presence and
>>> the type of floppy drives via corresponding ACPI objects.
>> I'm late to the party, but please allow me a question:
>> how did you figure out that UEFI Windows requires this?
>> In general, what the ACPI specification says is at best a "guideline"
>> for Windows. So how did you prove this was a requirement for Windows?
> Well, my statement above that Windows on UEFI can detect floppies *only*
> via ACPI is probably a bit stronger than I can actually prove but
> - Windows on OVMF didn't see floppies before the patch, while Linux did
> (by querying CMOS)
> - a number of sources on the internet hinted that Windows needed ACPI
> assistance for that, e.g.:
Right, I found these. (The last two anyway.)
I also found technet comments that plainly stated "it would never work".
(Under your first link, I can read as well: "There have been reports
that Windows does not properly support motherboard floppy controllers
when booting from UEFI. The cause is not definitively known though a
couple of pieces of data have emerged, one pointing to an issue with ACPI".)
> - the links mentioned the need in _FDE object but indicated it only
> allowed for successful enumeration of floppies, not the actual access;
> I proved that experimentally
> - the ACPI spec stated that _FDE went in concert with _FDI so I tried it
> and it worked out
Thank you for confirming.
So, improving Windows compat in QEMU remains trial-and-error-based, and
occasionally reverse-engineering-based. Deplorable.
> Voila. Besides, I later discovered that a similar research had been
> carried out for Parallels proprietary hypervisor, with a similar
That is, large amounts of work are being duplicated between participants
in this industry segment, because Microsoft doesn't give a flying fsck
about documenting their exact platform requirements. (The fact that _FDE
and _FDI are described in the ACPI spec means exactly zilch, because
Microsoft have ignored e.g. DataTableRegion from the same spec, since
ACPI 2.0 -- the year 2000.) I'm quite sure this obscurity is
intentional, and meant to spread uncertainty and waste competitors'
Whereas they are having a field day whenever they look at open source
components in a hybrid virt stack.
Nothing to see here, move along.