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