Re: [Qemu-devel] [Qemu-block] [PATCH v4 00/12] fdc: fix 2.88mb floppy diskette support

[John Snow <jsnow@redhat.com>]

On 01/21/2016 05:53 AM, Roman Kagan wrote:
> On Wed, Jan 20, 2016 at 02:40:14PM -0500, John Snow wrote:
>> On 01/20/2016 02:55 AM, Denis V. Lunev wrote:
>>> should we recreate ACPI tables after geometry switch?
>>> This would be especially interesting for the case of
>>> Win2k12 (or Win8.1 if you prefer) under OVMF.
>>>
>>> Den
>>
>> This series doesn't really alter the concept that disk geometry can
>> change at runtime -- Not knowing much about the ACPI reverse engineering
>> that happened to make Windows 8/10 happy, does it work currently? Can
>> you change to different density floppies and have it work out alright?
> 
> No, exactly because the geometry is determined once startup.
> 
>> If not, you can submit a patch against master as it is today -- this
>> series only does two things:
>>
>> (1) Alters the heuristics for which type of floppy drive is chosen at
>> boot time (No change to ACPI table generation should be needed.)
>>
>> (2) Allows 1.44MB diskettes to be recognized by 2.88MB drive types. This
>> might require some changes, but check out pick_geometry both before and
>> after this patchset -- there's a whole table of different geometries
>> that we already allow users to switch between at runtime. If the
>> geometry needs to update there, too, then it's already broken before
>> this patchset.
> 
> Right.
> 
> This series conflicts slightly with the patches to generate ACPI objects
> for floppies (which haven't made it into the mainstream qemu yet)
> because of the adjustments in the floppy API.  Not a big deal.
> 
>> It should be easy enough to slide a geometry update in fd_revalidate()
>> if needed.
> 
> Now that is a bit trickier: the currently submitted code queries the
> floppy properties at SSDT build time, and sticks static objects into
> AML; if that really needs updating at runtime it'll require certain
> refactoring.
> 
> That said I'm not certain what exactly has to be done here.  Physical
> machines do not have their floppy drives changable at runtime, do they?
> So the OSes should be fine assuming that the drive stays the same, and
> it's only the diskette that can change.  I'd guess that the OS driver
> should do the necessary revalidation on its own, without ACPI
> assistance; I'll give it a try when I have some time.
> 
> But again, as you said, people are mainly interested in floppies to
> bootstrap a Windows installation on virtio disks, so support of floppy
> geometry update at runtime is non-critical for most users.
> 
> Thanks,
> Roman.
> 

I'm a little confused here. I am not proposing the ability to change a
floppy drive type at runtime, just the ability to insert different kinds
of diskettes, which does happen in the real world.

e.g. a 2.88MB capable floppy drive that can read either 1.44MB or 2.88MB
types.

--js