qemu-block
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Roman Kagan
Subject: Re: [Qemu-block] [PATCH v4 00/12] fdc: fix 2.88mb floppy diskette support
Date: Thu, 21 Jan 2016 13:53:48 +0300
User-agent: Mutt/1.5.24 (2015-08-30)

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.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]