From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:38604) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aTYNb-0006yq-6a for qemu-devel@nongnu.org; Wed, 10 Feb 2016 12:16:44 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aTYNX-00077d-6E for qemu-devel@nongnu.org; Wed, 10 Feb 2016 12:16:39 -0500 Received: from mx1.redhat.com ([209.132.183.28]:56784) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aTYNW-00077Z-WB for qemu-devel@nongnu.org; Wed, 10 Feb 2016 12:16:35 -0500 References: <1454612376-7072-1-git-send-email-mst@redhat.com> <1454612376-7072-49-git-send-email-mst@redhat.com> <20160205192507.41fc6024@nial.brq.redhat.com> <20160208131443.GC6420@rkaganb.sw.ru> <56B8F89F.3090603@redhat.com> <20160209155249.GA13787@rkaganb.sw.ru> <56BA1229.8090809@redhat.com> <56BA319C.9010505@redhat.com> <20160210171018.GG9169@rkaganb.sw.ru> From: John Snow Message-ID: <56BB7070.90002@redhat.com> Date: Wed, 10 Feb 2016 12:16:32 -0500 MIME-Version: 1.0 In-Reply-To: <20160210171018.GG9169@rkaganb.sw.ru> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PULL 48/49] i386: populate floppy drive information in DSDT List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Roman Kagan , Laszlo Ersek , Igor Mammedov , "Michael S. Tsirkin" , qemu-devel@nongnu.org, Peter Maydell , Eduardo Habkost , Paolo Bonzini , Richard Henderson 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. >