[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [PULL 48/49] i386: populate floppy drive information in
From: |
Kevin O'Connor |
Subject: |
Re: [Qemu-devel] [PULL 48/49] i386: populate floppy drive information in DSDT |
Date: |
Sat, 13 Feb 2016 12:26:53 -0500 |
User-agent: |
Mutt/1.5.24 (2015-08-30) |
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 <address@hidden>
> >>>> 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.
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
- Re: [Qemu-devel] [PULL 48/49] i386: populate floppy drive information in DSDT, (continued)
- Re: [Qemu-devel] [PULL 48/49] i386: populate floppy drive information in DSDT, John Snow, 2016/02/09
- Re: [Qemu-devel] [PULL 48/49] i386: populate floppy drive information in DSDT, Laszlo Ersek, 2016/02/09
- Re: [Qemu-devel] [PULL 48/49] i386: populate floppy drive information in DSDT, Michael S. Tsirkin, 2016/02/09
- Re: [Qemu-devel] [PULL 48/49] i386: populate floppy drive information in DSDT, John Snow, 2016/02/10
- Re: [Qemu-devel] [PULL 48/49] i386: populate floppy drive information in DSDT, Michael S. Tsirkin, 2016/02/10
- Re: [Qemu-devel] [PULL 48/49] i386: populate floppy drive information in DSDT, Roman Kagan, 2016/02/10
- Re: [Qemu-devel] [PULL 48/49] i386: populate floppy drive information in DSDT, Roman Kagan, 2016/02/10
- Re: [Qemu-devel] [PULL 48/49] i386: populate floppy drive information in DSDT, John Snow, 2016/02/10
- Re: [Qemu-devel] [PULL 48/49] i386: populate floppy drive information in DSDT, Roman Kagan, 2016/02/10
- Re: [Qemu-devel] [PULL 48/49] i386: populate floppy drive information in DSDT, John Snow, 2016/02/10
- Re: [Qemu-devel] [PULL 48/49] i386: populate floppy drive information in DSDT,
Kevin O'Connor <=
- Re: [Qemu-devel] [PULL 48/49] i386: populate floppy drive information in DSDT, Laszlo Ersek, 2016/02/14
- Re: [Qemu-devel] [PULL 48/49] i386: populate floppy drive information in DSDT, Michael S. Tsirkin, 2016/02/14
- Re: [Qemu-devel] [PULL 48/49] i386: populate floppy drive information in DSDT, Roman Kagan, 2016/02/17
- Re: [Qemu-devel] [PULL 48/49] i386: populate floppy drive information in DSDT, Roman Kagan, 2016/02/10
[Qemu-devel] [PULL 47/49] expose floppy drive geometry and CMOS type, Michael S. Tsirkin, 2016/02/04
[Qemu-devel] [PULL 49/49] acpi: update expected DSDT, Michael S. Tsirkin, 2016/02/04
Re: [Qemu-devel] [PULL 00/49] pc and misc cleanups and fixes, virtio optimizations, Peter Maydell, 2016/02/05