From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:35318) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aUyBu-000891-V4 for qemu-devel@nongnu.org; Sun, 14 Feb 2016 10:02:28 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aUyBp-0007j3-V5 for qemu-devel@nongnu.org; Sun, 14 Feb 2016 10:02:26 -0500 Received: from mx1.redhat.com ([209.132.183.28]:60464) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aUyBp-0007ir-Nl for qemu-devel@nongnu.org; Sun, 14 Feb 2016 10:02:21 -0500 Date: Sun, 14 Feb 2016 17:02:14 +0200 From: "Michael S. Tsirkin" Message-ID: <20160214165300-mutt-send-email-mst@redhat.com> 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> <20160213172653.GA9029@morn.lan> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20160213172653.GA9029@morn.lan> 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: Kevin O'Connor Cc: Peter Maydell , Eduardo Habkost , John Snow , qemu-devel@nongnu.org, Roman Kagan , Igor Mammedov , Paolo Bonzini , Laszlo Ersek , Richard Henderson On Sat, Feb 13, 2016 at 12:26:53PM -0500, Kevin O'Connor wrote: > On Tue, Feb 09, 2016 at 07:36:12PM +0100, Laszlo Ersek wrote: > > On 02/09/16 17:22, John Snow wrote: > > > On 02/09/2016 10:52 AM, Roman Kagan wrote: > > >> On Mon, Feb 08, 2016 at 03:20:47PM -0500, John Snow wrote: > > >>> On 02/08/2016 08:14 AM, Roman Kagan wrote: > > >>>> On Fri, Feb 05, 2016 at 07:25:07PM +0100, Igor Mammedov wrote: > > >>>>>> + aml_append(fdi, > > >>>>>> + aml_int(cylinders - 1)); /* Maximum Cylinder Number */ > > >>>>> this puts uint64_t(-1) in AML i.e. cylinders == 0 and overflow happens here > > >>>>> > > >>>>> CCing Jon > > >>>> > > >>>> I guess this is the effect of John's fdc rework. I used to think zero > > >>>> geometry was impossible at the time this patch was developed. > > >>>> > > >>>> I wonder if it hasn't been fixed already by > > >>>> > > >>>> commit fd9bdbd3459e5b9d51534f0747049bc5b6145e07 > > >>>> Author: John Snow > > >>>> Date: Wed Feb 3 11:28:55 2016 -0500 > > >>>> > > >>>> fdc: fix detection under Linux > > >>> > > >>> Yes, hopefully solved on my end. The geometry values for an empty disk > > >>> are not well defined (they certainly don't have any *meaning*) so if you > > >>> are populating tables based on an empty drive, I just hope you also have > > >>> the mechanisms needed to update said tables when the media changes. > > >> > > >> I don't. At the time the patch was developed there basically were no > > >> mechanisms to update the geometry at all (and this was what you patchset > > >> addressed, in particular, wasn't it?) so I didn't care. > > >> > > > > > > That's not true. > > > > > > You could swap different 1.44MB-class diskettes for other geometries, > > > check this out: > > > > > > static const FDFormat fd_formats[] = { > > > /* First entry is default format */ > > > /* 1.44 MB 3"1/2 floppy disks */ > > > { FDRIVE_DRV_144, 18, 80, 1, FDRIVE_RATE_500K, }, > > > { FDRIVE_DRV_144, 20, 80, 1, FDRIVE_RATE_500K, }, > > > { FDRIVE_DRV_144, 21, 80, 1, FDRIVE_RATE_500K, }, > > > { FDRIVE_DRV_144, 21, 82, 1, FDRIVE_RATE_500K, }, > > > { FDRIVE_DRV_144, 21, 83, 1, FDRIVE_RATE_500K, }, > > > { FDRIVE_DRV_144, 22, 80, 1, FDRIVE_RATE_500K, }, > > > { FDRIVE_DRV_144, 23, 80, 1, FDRIVE_RATE_500K, }, > > > { FDRIVE_DRV_144, 24, 80, 1, FDRIVE_RATE_500K, }, > > > ... > > > > > > You absolutely could get different sector and track counts before my > > > patchset. > > > > > > > > >> Now if it actually has to be fully dynamic it's gonna be more > > >> involved... > > >> > > >>> What do the guests use these values for? Are they fixed at boot? > > >> > > >> Only Windows guests use it so it's hard to tell. I can only claim that > > >> if I stick bogus values into that ACPI object the guest fails to read > > >> the floppy. > > > > We discussed this with John a bit on IRC. > > > > 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) > > FWIW, that's not how I read the ACPI specification. I read it as > saying that the information should be filled with the maximum number > of CHS that the drive can support. So, even if a smaller disk happens > to be in the drive the maximum the drive supports would not change. I agree. It says: This object returns information about a floppy disk drive. This information is the same as that returned by the INT 13 Function 08H on Intel Architecture PCs. So disk drive, not disk information. And FWIW I have an old "the undocumented PC" book which says this about int 13h function 8 (read diskette drive parameters): "Remember this data is *not* the limits of the media in the drive, but the maximum capability of the specified drive". > Also, FWIW, SeaBIOS uses the standard 1.44MB floppy controller timing > information even if a 5.25 drive is found - as far as I know this > information is only ever used on PIO to the floppy controller and the > QEMU floppy controller doesn't care what timing parameters it is > programmed with. > > -Kevin