qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Review of onboard block device configuration with -drive


From: Markus Armbruster
Subject: Review of onboard block device configuration with -drive
Date: Tue, 03 Dec 2019 22:01:01 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/26.2 (gnu/linux)

To the best of my knowledge, -blockdev can fully replace -drive if=none.
Replacing other interface types takes more than just -blockdev, because
they additionally instruct the board code to create a block frontend.
-blockdev is *only* about backends, so something else needs to replace
the frontend part.

The common tool to create frontends is -device.  To replace -drive, we
use -blockdev with -device.  For instance, -drive if=scsi,media=disk can
be replaced by -blockdev with -device scsi-hd.  In general, the
replacement depends on the machine type.

In some cases, board code can create multiple devices.  For instance,
some board code can create SCSI HBAs in addition to SCSI devices.  We
need multiple -device then.

This method is workable as long as all of the devices are available with
-device ("pluggable").  For the cases that create "non-pluggable"
devices, we need another replacement.

Example: pflash devices are not pluggable.  To replace -drive
if=plflash, We chose to add machine properties that forward to the
onboard pflash devices' "drive" properties.  Done for i386 machines
i440fx*, q35*, isapc, arm machines virt, sbsa-ref, riscv machine virt,
in these commits:

    ebc29e1bea pc: Support firmware configuration with -blockdev
    e0561e60f1 hw/arm/virt: Support firmware configuration with -blockdev
    e9fdf45324 hw/arm: Add arm SBSA reference machine, devices part
    71eb522c40 riscv/virt: Add the PFlash CFI01 device

For all the other machines sporting pflash devices, -drive if=pflash
remains the only way to configure them.  As long as that's the case, we
can't deprecate -drive entirely.

Let's review where exactly we stand on replacing -drive in the frontend
configuration role.  Problematic cases are marked with "-drive is the
only way to ...".  Beware, I might misread the code, especially for the
more exotic machines.

The interface types are:

* if=none

  There is nothing to replace.

* if=ide

  ARM machines spitz, borzoi, terrier, and tosa recognize bus=0,unit=0.
  If present, they create a dscm1xxxx device with the appropriate IDE
  device (ide-hd or ide-cd) plugged in.  dscm1xxxx is not pluggable, and
  -drive is the only way to create it.

  Several other machines have onboard IDE controllers.  Board code
  recognizes their bus numbers, and creates the appropriate IDE devices
  for all the unit numbers.  You can create them with -device instead.

* if=scsi

  ARM machines realview-eb*, versatile* create as many lsi53c895a SCSI
  HBAs as needed to provide all the bus numbers used with -drive
  if=scsi.  PPC machines pseries* similarly create spapr-vscsi SCSI
  HBAs.

  Each SCSI HBA so created then recognizes its own bus number, and
  creates the appropriate SCSI devices (scsi-hd, scsi-cd or
  scsi-generic) for all the unit numbers.

  Dirt effect: lsi53c895a and spapr-vscsi do that even when added with
  -device.  No other SCSI HBA does.  This usage is deprecated.

  All these devices can be created with -device instead.

  HPPA machine hppa, M68k machine q800, Mips machines magnum, pica61,
  PPC machine 40p, and the sun4m SPARC machines have an onboard SCSI
  HBA.  Board code recognizes bus number 0, and creates the appropriate
  SCSI devices for the unit numbers.

* if=floppy

  i386 machines pc*, isapc and xenfv recognize bus=0,unit=[01].  Unless
  both are absent, they create an isa-fdc controller with the approriate
  floppy devices.

  All these devices can be created with -device instead.

  Mips machines magnum, pica61, SPARC machines sun4u, sun4v have an
  onboard floppy controller.  They recognize bus=0,unit=[01], and create
  the appropriate floppy devices.

  SPARC sun4m machines other than SS-600MP do the same, except they
  recognize only unit=0.

  Devices fdc37m81x-superio, pc87312, smc37c669-superio,
  vt82c686b-superio (all children of isa-superio) recognize
  bus=0,unit=[01], and create the appropriate floppy devices.  This is
  inappropriate for device code, and marked FIXME.  -drive is the only
  way to connect backends to these devices.

* if=pflash

  Many machines have onboard pflash devices.  They recognize
  bus=0,unit=U where 0 <= U < number of such onboard devices.  ARM
  machine sbsa-ref, virt, i386 machines pc*, isapc, xenfv, Risc-V
  machine virt provide machine properties for connecting backends to
  their onboard pflash devices.  For the other machines, -drive is still
  the only way to connect backends.

  PPC machines pseries* create spapr-nvram devices instead.  It can be
  created with -device instead.

  SPARC machine niagara creates a memory region instead *boggle*.
  -drive is the only way to configure that.

  Other machines create the onboard pflash device only when the
  corresponing drive is present.  Since pflash devices are not
  pluggable, -drive is the only way to create them.

* if=mtd

  Many machines have onboard flash devices other than pflash.  They
  recognize bus=0,unit=U where 0 <= U < number of such onboard devices.
  -drive is the only way to connect backends.

  ARM machines ast*-evb, *-bmc additionally create a memory region for
  bus=0,unit=0.  -drive is the only way to configure that.

* if=sd

  Many machines have onboard sd-card devices.  They recognize
  bus=0,unit=U where 0 <= U < number of such onboard devices.  -drive is
  the only way to connect backends.

* if=virtio

  This is effectively sugar for -drive with -device virtio-blk-pci,
  except for qemu-system-s390x, where it's virtio-blk-ccw instead.

* if=xen

  i386 machine xenpv puts the configuration into xenstore, which makes
  stuff happen.  In other words: I have no clue.  I figure -drive is the
  only way to make this stuff happen.

How did I find this information?  The result of -drive is encapsulated,
and board code has to use drive_get(), drive_get_by_index(), or
drive_get_next() to access it.  I reviewed their callers.

Summary

* if=none, if=scsi, if=virtio could be deprecated now, because they have
  replacements.

* if=ide is blocked by the dscm1xxxx issue.  I suspect making it
  conditional on -drive is a mistake.  If we make it unconditional, we
  should be able to deprecate if=ide.

* if=floppy is blocked by the isa-superio issue.  Fixing that FIXME
  should let us deprecate if=floppy.

* if=pflash, if=mtd and if=sd are blocked by the "no way to connect
  backends to onboard devices" issue, and the "no way to create the
  device" issue.  We solved them for if=pflash with some boards.  Many
  more remain.

* if=xen: no clue.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]