On 02/13/16 18:26, 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 <js...@redhat.com> >>>>>> 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.
If that works with Windows, I think it would be optimal for QEMU. Thanks! Laszlo > > 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 >