From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:46219) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aMGhl-0007fg-Nd for qemu-devel@nongnu.org; Thu, 21 Jan 2016 09:59:24 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aMGhf-0003XA-TP for qemu-devel@nongnu.org; Thu, 21 Jan 2016 09:59:21 -0500 References: <1453272694-17106-1-git-send-email-jsnow@redhat.com> <569F3D8B.8000607@parallels.com> <569FE29E.1060901@redhat.com> <20160121105348.GB3947@rkaganb.sw.ru> From: John Snow Message-ID: <56A0F23D.9040304@redhat.com> Date: Thu, 21 Jan 2016 09:59:09 -0500 MIME-Version: 1.0 In-Reply-To: <20160121105348.GB3947@rkaganb.sw.ru> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit 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: Roman Kagan , "Denis V. Lunev" , qemu-block@nongnu.org, kwolf@redhat.com, armbru@redhat.com, qemu-devel@nongnu.org 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