Re: [Qemu-devel] [PATCH] Do not emulate a floppy drive when -nodefaults

["Michael S. Tsirkin" <mst@redhat.com>]

On Thu, May 14, 2015 at 12:18:26PM +0100, Daniel P. Berrange wrote:
> On Thu, May 14, 2015 at 12:12:52PM +0100, Stefano Stabellini wrote:
> > On Wed, 13 May 2015, John Snow wrote:
> > > 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.
> > 
> > That was my impression too.
> > 
> > 
> > 
> > On Thu, 14 May 2015, Stefan Weil wrote:
> > > Am 13.05.2015 um 20:15 schrieb Stefano Stabellini:
> > > > 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.
> > > 
> > > A short test on some of my physical machines shows that most
> > > of them don't have a floppy disk controller at all (dmesg | grep FDC).
> > > 
> > > Only some older machines still have one.
> > > 
> > > Therefore I think that QEMU must also be able to offer a virtual
> > > machine without an FDC, maybe as the default for the next
> > > version of QEMU.
> > 
> > I think it would make sense to make it the default for -nodefaults
> > machines. I would be OK with a new property too, as we could set it from
> > libxl or libvirt. Anybody would be happy to pick this one up or should I
> > do it?
> 
> It isn't permissible to change the hardware exposed to guests for existing
> machine types, even when -nodefaults is used. Any change in defaults has
> to be for new machine types only. eg we can't change pc-2.3.0 machine
> type, but we could change defaults for the pc-2.4.0 machine type that
> will be in next release. That ensures migration upgrade compatibility
> for existing guests, while letting new guests get the new defaults.
> 
> Regards,
> Daniel

For libvirt, yes. But command-line users might rely on the old behaviour
with e.g. -M pc so we shouldn't change defaults lightly even for new
machine types.



> -- 
> |: http://berrange.com      -o-    http://www.flickr.com/photos/dberrange/ :|
> |: http://libvirt.org              -o-             http://virt-manager.org :|
> |: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
> |: http://entangle-photo.org       -o-       http://live.gnome.org/gtk-vnc :|