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

["Daniel P. Berrange" <berrange@redhat.com>]

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
-- 
|: 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 :|