From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:48633) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aMCsN-0005lo-A3 for qemu-devel@nongnu.org; Thu, 21 Jan 2016 05:54:04 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aMCsI-0000CV-BV for qemu-devel@nongnu.org; Thu, 21 Jan 2016 05:54:03 -0500 Date: Thu, 21 Jan 2016 13:53:48 +0300 From: Roman Kagan Message-ID: <20160121105348.GB3947@rkaganb.sw.ru> References: <1453272694-17106-1-git-send-email-jsnow@redhat.com> <569F3D8B.8000607@parallels.com> <569FE29E.1060901@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline In-Reply-To: <569FE29E.1060901@redhat.com> Subject: Re: [Qemu-devel] [Qemu-block] [PATCH v4 00/12] fdc: fix 2.88mb floppy diskette support List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: John Snow Cc: kwolf@redhat.com, qemu-devel@nongnu.org, armbru@redhat.com, qemu-block@nongnu.org, "Denis V. Lunev" 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.