On 02/10/2016 12:10 PM, Roman Kagan wrote: > On Tue, Feb 09, 2016 at 07:36:12PM +0100, Laszlo Ersek wrote: >> In my opinion, the real mess in this case is in the ACPI spec itself. If >> you re-read the _FDI control method's description, the Package that it >> returns contains *dynamic* geometry data, about the *disk* (not *drive*): >> >> - Maximum Cylinder Number // Integer (WORD) >> - Maximum Sector Number // Integer (WORD) >> - Maximum Head Number // Integer (WORD) >> >> What this seems to require is: the firmware developer should write ACPI >> code that >> - dynamically accesses the floppy drive / controller (using MMIO or IO >> port registers), >> - retrieves the geometry of the disk actually inserted, >> - and returns the data nicely packaged. >> >> In effect, an ACPI-level driver for the disk. >> >> Now, John explained to me (and please keep in mind that this is my >> personal account of his explanation, not a factual rendering thereof), >> that there used to be no *standard* way to interrogate the current >> disk's geometry, other than trial and error with seeking. >> >> Apparently in UEFI Windows, Microsoft didn't want to implement this >> trial and error seeking, so -- given there was also no portable >> *hardware spec* to retrieve the same data, directly from the disk drive >> or controller -- they punted the entire question to ACPI. That is, to >> the firmware implementor. > > Well, as I wrote in another mail, SeaBIOS, which is supposed to provide > the same information to int 0x13/0x08, populates it with static data > based only on the drive type as encoded in CMOS at initialization time, > and everyone seem to have been fine with that so far. I'll need to > re-test it with real Windows guests, though. >
OK, but what we appear to be doing currently is polling the current geometry values for a drive instead of some pre-chosen ones based on the drive type. What values does SeaBIOS use? (Can you point me to the table it uses?) We could just duplicate those, probably. >> IMHO, do the *absolute minimum* to adapt this AML generation patch to >> John's FDC rework, and ignore all dynamic aspects (like media change). > > Hopefully that'll suffice. > > Roman. >
