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

[Markus Armbruster <armbru@xxxxxxxxxx>]

"Daniel P. Berrange" <berrange@xxxxxxxxxx> writes:

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

Correct.

Here's how I think it should be done:

* Create a machine option to control the FDC

  This is a machine-specific option.  It should only exist for machine
  types that have an optional FDC.

  Default must be "on" for old machine types.  Default may be "off" for
  new machine types.

  It should certainly be off for pc-q35-2.4 and newer.  Real Q35 boards
  commonly don't have an FDC (depends on the Super I/O chip used).

  We may want to keep it off for pc-i440fx-2.4 and newer.  I doubt
  there's a real i440FX without an FDC, but our virtual i440FX is quite
  unlike a real one in other ways already.

* Create the FDC only if the option is "on".

* Optional: make -drive if=floppy,... auto-enable it

  I wouldn't bother doing the same for -global isa-fdc.driveA=... and
  such.

Stefano, if you're willing to tackle this, go right ahead!

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel