[Qemu-devel] [PATCH v2 0/3] blockdev: Defer creation of implicit PCI devices for IF_VIRTIO drives

[Peter Maydell]

This is a respin of the patchset I sent out last week; the
only change v1->v2 is to drop the special casing of S390, as
Christian confirmed it isn't needed. This collapses the old
patches 2/3 into one.

I'm going to use this cover letter as an opportunity to (a) hopefully
be a bit clearer about the intention and (b) try to summarise the
current behaviour and possible improvements.

Patchset Rationale
==================

blockdev.c will create implicit virtio-blk-* devices for IF_VIRTIO
drives. I want to turn this on for the ARM virt board (now it has PCI),
so that users can use shorter and more comprehensible command lines,
including the "-hda" very-short convenience options. In particular I'm
getting justified complaints that the virt board's command line
requirements for disk specification are complicated and different from x86.

(The virt board currently ends up with the default default drive type,
which is IDE, which is totally useless as there is no IDE controller.)

Patch 3 is the one-liner to change the default-drive-type. Unfortunately
just doing that alone will break commandlines that currently work and
are I think relatively common with people using this board, like:

  -drive file=arm-wheezy.qcow2,id=foo
  -device virtio-blk-pci,drive=foo

(Note the lack of an if= specifier.) This works in current master
because nothing complains about the fact you've (implicitly) specified
an if=ide drive on a machine with no IDE drive, or about the fact
you've just plugged an if=ide drive into a virtio-blk device.

I *really* want to be able to set the default drive type to IF_VIRTIO;
if I have to break command lines like the above in order to do so,
I can put up with that, but I'm hoping we can do better than that.

Current situation
=================

At the moment we somewhat under-check uses of the if=foo option to
drives:
 * we do check that drives are not completely orphaned
 * we do insist that drives aren't connected twice
 * we don't directly check that an if=ide drive is actually plugged
   into an IDE controller (ditto SCSI, virtio, etc etc)

The "no double connection" rule means we will indirectly notice
some if= mismatches: if the machine has a bus of the correct type
and claims an if=foo drive, then this will get a connected-twice
error (from the automatic-claiming, and from the user-specified
commandline connection). However if the machine doesn't have a bus
of the relevant type and so doesn't auto-claim the drive, we won't
detect any problem. So x86_64 is inconsistent:

 qemu-system-x86_64 -nodefaults -display none -drive 
if=scsi,file=tmp.qcow2,id=foo -device ide-hd,drive=foo

fails, but

 qemu-system-x86_64 -nodefaults -display none -drive 
if=sd,file=tmp.qcow2,id=foo -device ide-hd,drive=foo

does not, and will connect an "if=sd" drive to the IDE controller.

Where we might like to be
=========================

Some possibilities, presented without regard to back-compat:

Option A:

1) explicit if=foo drive manually wired up to a device is an error
   (and always diagnosed as such, not indirectly via it being double-used)
2) explicit if=none drive is never auto-claimed
3a) drive with no if= is exactly as if the user explicitly stated
    if=<board-default-type> and must be auto-claimed

[This is almost what we have right now, except we do 1 only
sporadically and accidentally, and so some users are probably
using option combos we'd like to have be illegal]

Option B:

1) and 2) as above, but instead of 3a):

3b) drive with no if=... means "if user wired it up to something on the
    command line, honour that; otherwise treat as if=<board default> and
    auto-claim

[This tries to make at least some of the option-combos do the
plausibly right thing. This series is trying to add that for virtio,
but other if= types are probably harder to deal with. I think the
semantics here are nice but I'm struggling to see how to implement it.]

Option C:

Any other reasonable suggestions?


If we can decide what we'd like the semantics to be (ideally with
some idea of how to implement them ;-)) I can have a stab at
writing some patches.

I do definitely want to enable short-options for virt for 2.4...

thanks
-- PMM


Peter Maydell (3):
  blockdev: Factor out create_implicit_virtio_device
  blockdev: Defer creation of implicit PCI devices for IF_VIRTIO drives
  hw/arm/virt: Make block devices default to virtio

 blockdev.c    | 55 +++++++++++++++++++++++++++++++++++++++----------------
 hw/arm/virt.c |  1 +
 2 files changed, 40 insertions(+), 16 deletions(-)

-- 
1.9.1