From: John Snow <jsnow@redhat.com> To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>, "Daniel P. Berrange" <berrange@redhat.com> Cc: pbonzini@redhat.com, rth@twiddle.net, xen-devel@lists.xensource.com, qemu-devel@nongnu.org, mst@redhat.com Subject: Re: [Qemu-devel] [PATCH] Do not emulate a floppy drive when -nodefaults Date: Wed, 13 May 2015 17:46:57 -0400 [thread overview] Message-ID: <5553C651.4060000@redhat.com> (raw) In-Reply-To: <alpine.DEB.2.02.1505131853420.20496@kaball.uk.xensource.com> On 05/13/2015 02:15 PM, Stefano Stabellini wrote: > On Wed, 13 May 2015, Daniel P. Berrange wrote: >> On Wed, May 13, 2015 at 06:29:46PM +0100, Stefano Stabellini wrote: >>> Do not emulate a floppy drive if no drives are supposed to be present. >>> >>> This fixes the behavior of -nodefaults, that should remove the floppy >>> drive (see docs/qdev-device-use.txt:Default Devices), but actually >>> doesn't. >> >> Technically that doc is just refering to the disablement of the >> primary floppy drive, as opposed to the floppy controller. The >> floppy controller itself is really a built-in device that is >> defined as part of the machine type, along with the various other >> platform devices hanging off the PIIX and ISA brige. > > I think you are right, this patch is a bit too harsh in fixing the > problem: I just wanted to properly disable drive emulation, because from > my tests the guest thinks that one drive is present even when is not. > We should just be a little careful in explaining the difference between the controller, the drives, and what circumstances things show up and to whom. Currently the FDC is always present and always has two drive objects that are directly inlined to that device. Now, based on whether or not this line fires in vl.c: default_drive(default_floppy, snapshot, IF_FLOPPY, 0, FD_OPTS); controls whether or not we find that drive in pc_basic_device_init as you've found, which controls (ultimately) whether or not fdctrl->drives[0].blk or fdctrl->drives[1].blk gets set. If the blk pointer is set, even if you have no media inserted, fd_revalidate (and pick_geometry) will *FORCIBLY PICK* a drive type for this floppy, currently a 1.44MB type, (20 sect, 80 track, 1 head) with a data rate of 500 Kbps. This is written to the rtc memory where seabios later reads it to discover if you have a guest-visible floppy drive there. Both QEMU and SeaBIOS confuse the concept of "A drive is present" with "A disk is present" which leads to these kinds of confusing scenarios. There's some work to do here, for sure. Anyway, maybe this patch is inappropriate: Just because we have no drives doesn't mean we don't have a controller. I have seen some discussion recently about allowing users to disable/remove the FDC altogether, though, and I think this is probably the way to go. > >>> diff --git a/hw/i386/pc.c b/hw/i386/pc.c >>> index a8e6be1..c9f50b3 100644 >>> --- a/hw/i386/pc.c >>> +++ b/hw/i386/pc.c >>> @@ -1410,6 +1410,7 @@ void pc_basic_device_init(ISABus *isa_bus, qemu_irq *gsi, >>> qemu_irq *cpu_exit_irq; >>> MemoryRegion *ioport80_io = g_new(MemoryRegion, 1); >>> MemoryRegion *ioportF0_io = g_new(MemoryRegion, 1); >>> + bool floppy_exist; >>> >>> memory_region_init_io(ioport80_io, NULL, &ioport80_io_ops, NULL, "ioport80", 1); >>> memory_region_add_subregion(isa_bus->address_space_io, 0x80, ioport80_io); >>> @@ -1487,10 +1488,17 @@ void pc_basic_device_init(ISABus *isa_bus, qemu_irq *gsi, >>> cpu_exit_irq = qemu_allocate_irqs(cpu_request_exit, NULL, 1); >>> DMA_init(0, cpu_exit_irq); >>> >>> + *floppy = NULL; >>> + floppy_exist = false; >>> for(i = 0; i < MAX_FD; i++) { >>> fd[i] = drive_get(IF_FLOPPY, 0, i); >>> + if (fd[i] != NULL) { >>> + floppy_exist = true; >>> + } >>> + } >>> + if (floppy_exist) { >>> + *floppy = fdctrl_init_isa(isa_bus, fd); >>> } >>> - *floppy = fdctrl_init_isa(isa_bus, fd); >>> } >> >> This results in a guest ABI change when updating QEMU, because the floppy >> controller will disappear for existing guests. This is liable to break >> guests upon migration. >> >> If we want to be able to disable the floppy controller itself, in addition >> to the floppy drives, then we'd likely need to define a property against >> the machine type to allow its existence to be toggled on/off. We'd then >> need to at least make sure the existing machine types defaulted to on, >> if we decided that new machine types should default to off. >> >> Libvirt would also need to gain the ability to represent the existance >> of the floppy controller and allow it to be turned on / off explicitly. > >
WARNING: multiple messages have this Message-ID (diff)
From: John Snow <jsnow@redhat.com> To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>, "Daniel P. Berrange" <berrange@redhat.com> Cc: pbonzini@redhat.com, rth@twiddle.net, xen-devel@lists.xensource.com, qemu-devel@nongnu.org, mst@redhat.com Subject: Re: [PATCH] Do not emulate a floppy drive when -nodefaults Date: Wed, 13 May 2015 17:46:57 -0400 [thread overview] Message-ID: <5553C651.4060000@redhat.com> (raw) In-Reply-To: <alpine.DEB.2.02.1505131853420.20496@kaball.uk.xensource.com> On 05/13/2015 02:15 PM, Stefano Stabellini wrote: > On Wed, 13 May 2015, Daniel P. Berrange wrote: >> On Wed, May 13, 2015 at 06:29:46PM +0100, Stefano Stabellini wrote: >>> Do not emulate a floppy drive if no drives are supposed to be present. >>> >>> This fixes the behavior of -nodefaults, that should remove the floppy >>> drive (see docs/qdev-device-use.txt:Default Devices), but actually >>> doesn't. >> >> Technically that doc is just refering to the disablement of the >> primary floppy drive, as opposed to the floppy controller. The >> floppy controller itself is really a built-in device that is >> defined as part of the machine type, along with the various other >> platform devices hanging off the PIIX and ISA brige. > > I think you are right, this patch is a bit too harsh in fixing the > problem: I just wanted to properly disable drive emulation, because from > my tests the guest thinks that one drive is present even when is not. > We should just be a little careful in explaining the difference between the controller, the drives, and what circumstances things show up and to whom. Currently the FDC is always present and always has two drive objects that are directly inlined to that device. Now, based on whether or not this line fires in vl.c: default_drive(default_floppy, snapshot, IF_FLOPPY, 0, FD_OPTS); controls whether or not we find that drive in pc_basic_device_init as you've found, which controls (ultimately) whether or not fdctrl->drives[0].blk or fdctrl->drives[1].blk gets set. If the blk pointer is set, even if you have no media inserted, fd_revalidate (and pick_geometry) will *FORCIBLY PICK* a drive type for this floppy, currently a 1.44MB type, (20 sect, 80 track, 1 head) with a data rate of 500 Kbps. This is written to the rtc memory where seabios later reads it to discover if you have a guest-visible floppy drive there. Both QEMU and SeaBIOS confuse the concept of "A drive is present" with "A disk is present" which leads to these kinds of confusing scenarios. There's some work to do here, for sure. Anyway, maybe this patch is inappropriate: Just because we have no drives doesn't mean we don't have a controller. I have seen some discussion recently about allowing users to disable/remove the FDC altogether, though, and I think this is probably the way to go. > >>> diff --git a/hw/i386/pc.c b/hw/i386/pc.c >>> index a8e6be1..c9f50b3 100644 >>> --- a/hw/i386/pc.c >>> +++ b/hw/i386/pc.c >>> @@ -1410,6 +1410,7 @@ void pc_basic_device_init(ISABus *isa_bus, qemu_irq *gsi, >>> qemu_irq *cpu_exit_irq; >>> MemoryRegion *ioport80_io = g_new(MemoryRegion, 1); >>> MemoryRegion *ioportF0_io = g_new(MemoryRegion, 1); >>> + bool floppy_exist; >>> >>> memory_region_init_io(ioport80_io, NULL, &ioport80_io_ops, NULL, "ioport80", 1); >>> memory_region_add_subregion(isa_bus->address_space_io, 0x80, ioport80_io); >>> @@ -1487,10 +1488,17 @@ void pc_basic_device_init(ISABus *isa_bus, qemu_irq *gsi, >>> cpu_exit_irq = qemu_allocate_irqs(cpu_request_exit, NULL, 1); >>> DMA_init(0, cpu_exit_irq); >>> >>> + *floppy = NULL; >>> + floppy_exist = false; >>> for(i = 0; i < MAX_FD; i++) { >>> fd[i] = drive_get(IF_FLOPPY, 0, i); >>> + if (fd[i] != NULL) { >>> + floppy_exist = true; >>> + } >>> + } >>> + if (floppy_exist) { >>> + *floppy = fdctrl_init_isa(isa_bus, fd); >>> } >>> - *floppy = fdctrl_init_isa(isa_bus, fd); >>> } >> >> This results in a guest ABI change when updating QEMU, because the floppy >> controller will disappear for existing guests. This is liable to break >> guests upon migration. >> >> If we want to be able to disable the floppy controller itself, in addition >> to the floppy drives, then we'd likely need to define a property against >> the machine type to allow its existence to be toggled on/off. We'd then >> need to at least make sure the existing machine types defaulted to on, >> if we decided that new machine types should default to off. >> >> Libvirt would also need to gain the ability to represent the existance >> of the floppy controller and allow it to be turned on / off explicitly. > >
next prev parent reply other threads:[~2015-05-13 21:47 UTC|newest] Thread overview: 64+ messages / expand[flat|nested] mbox.gz Atom feed top 2015-05-13 17:29 [Qemu-devel] [PATCH] Do not emulate a floppy drive when -nodefaults Stefano Stabellini 2015-05-13 17:29 ` Stefano Stabellini 2015-05-13 17:42 ` [Qemu-devel] " Daniel P. Berrange 2015-05-13 17:42 ` Daniel P. Berrange 2015-05-13 18:15 ` [Qemu-devel] " Stefano Stabellini 2015-05-13 18:15 ` Stefano Stabellini 2015-05-13 21:46 ` John Snow [this message] 2015-05-13 21:46 ` John Snow 2015-05-14 11:12 ` [Qemu-devel] " Stefano Stabellini 2015-05-14 11:12 ` Stefano Stabellini 2015-05-14 11:18 ` [Qemu-devel] " Daniel P. Berrange 2015-05-14 11:18 ` Daniel P. Berrange 2015-05-14 11:46 ` [Qemu-devel] " Michael S. Tsirkin 2015-05-14 11:46 ` Michael S. Tsirkin 2015-05-14 12:02 ` [Qemu-devel] " Markus Armbruster 2015-05-14 12:02 ` Markus Armbruster 2015-05-14 12:11 ` [Qemu-devel] " Paolo Bonzini 2015-05-14 12:11 ` Paolo Bonzini 2015-05-14 12:45 ` [Qemu-devel] " Markus Armbruster 2015-05-14 12:45 ` Markus Armbruster 2015-05-14 12:48 ` [Qemu-devel] " Daniel P. Berrange 2015-05-14 12:48 ` Daniel P. Berrange 2015-05-14 12:53 ` [Qemu-devel] " Paolo Bonzini 2015-05-14 12:53 ` Paolo Bonzini 2015-05-14 13:25 ` [Qemu-devel] [Xen-devel] " Sander Eikelenboom 2015-05-14 13:25 ` Sander Eikelenboom 2015-05-14 13:41 ` [Qemu-devel] " Daniel P. Berrange 2015-05-14 13:41 ` Daniel P. Berrange 2015-05-14 13:55 ` [Qemu-devel] " Paolo Bonzini 2015-05-14 13:55 ` Paolo Bonzini 2015-05-14 14:39 ` [Qemu-devel] " Stefano Stabellini 2015-05-14 14:39 ` Stefano Stabellini 2015-05-14 14:44 ` [Qemu-devel] " Paolo Bonzini 2015-05-14 14:44 ` Paolo Bonzini 2015-05-14 14:52 ` [Qemu-devel] " Stefano Stabellini 2015-05-14 14:52 ` Stefano Stabellini 2015-05-14 13:57 ` [Qemu-devel] " Michael S. Tsirkin 2015-05-14 13:57 ` Michael S. Tsirkin 2015-05-14 14:07 ` [Qemu-devel] " Michael S. Tsirkin 2015-05-14 14:07 ` Michael S. Tsirkin 2015-05-14 17:54 ` [Qemu-devel] " John Snow 2015-05-14 17:54 ` John Snow 2015-05-15 7:50 ` [Qemu-devel] " Markus Armbruster 2015-05-15 7:50 ` Markus Armbruster 2015-05-15 8:19 ` [Qemu-devel] " Paolo Bonzini 2015-05-15 8:19 ` Paolo Bonzini 2015-05-15 10:20 ` [Qemu-devel] " Stefano Stabellini 2015-05-15 10:20 ` Stefano Stabellini 2015-05-18 9:19 ` [Qemu-devel] " Kevin Wolf 2015-05-18 9:19 ` Kevin Wolf 2015-05-14 11:47 ` [Qemu-devel] " Michael S. Tsirkin 2015-05-14 11:47 ` Michael S. Tsirkin 2015-05-14 11:54 ` [Qemu-devel] " Paolo Bonzini 2015-05-14 11:54 ` Paolo Bonzini 2015-05-14 11:56 ` [Qemu-devel] " Michael S. Tsirkin 2015-05-14 11:56 ` Michael S. Tsirkin 2015-05-14 12:47 ` [Qemu-devel] " Markus Armbruster 2015-05-14 12:47 ` Markus Armbruster 2015-05-14 4:38 ` [Qemu-devel] " Stefan Weil 2015-05-14 4:38 ` Stefan Weil 2015-05-14 5:45 ` [Qemu-devel] " Michael S. Tsirkin 2015-05-14 5:45 ` Michael S. Tsirkin 2015-05-13 21:44 ` [Qemu-devel] " Michael S. Tsirkin 2015-05-13 21:44 ` Michael S. Tsirkin
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=5553C651.4060000@redhat.com \ --to=jsnow@redhat.com \ --cc=berrange@redhat.com \ --cc=mst@redhat.com \ --cc=pbonzini@redhat.com \ --cc=qemu-devel@nongnu.org \ --cc=rth@twiddle.net \ --cc=stefano.stabellini@eu.citrix.com \ --cc=xen-devel@lists.xensource.com \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.