[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [PATCH 1/4] block: Warn if an if=<something> drive was
From: |
Peter Maydell |
Subject: |
Re: [Qemu-devel] [PATCH 1/4] block: Warn if an if=<something> drive was also connected manually |
Date: |
Mon, 22 Jun 2015 14:39:52 +0100 |
On 22 June 2015 at 10:59, Markus Armbruster <address@hidden> wrote:
> What about this instead:
>
> 1. When -device creation connects a qdev_prop_drive property to a
> backend, fail when the backend has a DriveInfo and the DriveInfo has
> type != IF_NONE. Note: the connection is made in parse_drive().
So, the reason I didn't do this is that it breaks some options
that currently work (the ones where the board doesn't pick up
the device and so there's no conflict). I preferred to make those
"continue to function, but warn", but if we're happy to make this
a hard error we could go this way.
> 2. This breaks -drive if=virtio and possibly more. That's because for
> if=virtio, we create input for -device creation that asks to connect
> this IF_VIRTIO drive. To unbreak it, mark the DriveInfo when we create
> such input, and make parse_drive() accept backends so marked. To find
> the places that need to mark, examine users of option group "device". A
> quick, sloppy grep shows a bit over a dozen candidates. Not too bad.
How do we then tell the difference between parse_drive() being called
for the auto-created virtio device, and it then later being called as
part of connecting the drive to a manually created device?
My grep (which was for 'qemu_find_opts.*device' -- is that right?)
suggests that in fact the only case we need to care about is the
one where we auto-create the virtio device (the other grep matches
are not relevant).
> In my opinion, a board that specifies a default interface type it
> doesn't support is simply broken, and should be fixed.
I'm inclined to agree, but I bet we have a lot. It doesn't help
that the default if the machine doesn't specify anything is "IDE",
not "you can't use a default interface"...
> Even if we fix that, we could still reach this case when the board
> claims only *some* of the drives for its default type. Example:
>
> $ qemu-system-x86_64 -nodefaults -S -display none -drive
> if=floppy,file=tmp.qcow2,index=99
> Warning: Orphaned drive without device:
> id=floppy99,file=tmp.qcow2,if=floppy,bus=0,unit=99
>
> Compare:
>
> $ qemu-system-x86_64 -nodefaults -S -display none -drive
> if=ide,file=tmp.qcow2,index=99
> qemu-system-x86_64: Too many IDE buses defined (50 > 2)
>
> Crap shot.
>
> If we have boards that don't claim *any* interface type, we need to give
> them a .block_default_type that rejects -drive without an explicit if=.
We have several of these boards, yes. (for example, hw/arm/cubieboard.c)
thanks
-- PMM
[Qemu-devel] [PATCH 2/4] qdev-properties-system: Change set_pointer's parse callback to use Error, Peter Maydell, 2015/06/12
Re: [Qemu-devel] [PATCH 0/4] block: Improve warnings for doubly-connected drives, Peter Maydell, 2015/06/19