From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:53957) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aTB3H-0003Nz-7w for qemu-devel@nongnu.org; Tue, 09 Feb 2016 11:22:08 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aTB3D-0008O2-V3 for qemu-devel@nongnu.org; Tue, 09 Feb 2016 11:22:07 -0500 Received: from mx1.redhat.com ([209.132.183.28]:47912) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aTB3D-0008Nh-OL for qemu-devel@nongnu.org; Tue, 09 Feb 2016 11:22:03 -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> From: John Snow Message-ID: <56BA1229.8090809@redhat.com> Date: Tue, 9 Feb 2016 11:22:01 -0500 MIME-Version: 1.0 In-Reply-To: <20160209155249.GA13787@rkaganb.sw.ru> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable 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 , Igor Mammedov , "Michael S. Tsirkin" , qemu-devel@nongnu.org, Peter Maydell , Eduardo Habkost , Paolo Bonzini , Richard Henderson 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 =3D=3D 0 and overflow h= appens here >>>> >>>> CCing Jon >>> >>> I guess this is the effect of John's fdc rework. I used to think zer= o >>> 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 y= ou >> are populating tables based on an empty drive, I just hope you also ha= ve >> the mechanisms needed to update said tables when the media changes. >=20 > 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 patchse= t > addressed, in particular, wasn't it?) so I didn't care. >=20 That's not true. You could swap different 1.44MB-class diskettes for other geometries, check this out: static const FDFormat fd_formats[] =3D { /* 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... >=20 >> What do the guests use these values for? Are they fixed at boot? >=20 > 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. >=20 > Roman. >=20 --=20 =97js