Re: [PATCH 11/12] hw/xen: automatically assign device index to block devices

[David Woodhouse <dwmw2@xxxxxxxxxxxxx>]

On Wed, 2023-10-18 at 10:52 +0200, Kevin Wolf wrote:
> Am 16.10.2023 um 17:19 hat David Woodhouse geschrieben:
> > From: David Woodhouse <dwmw@xxxxxxxxxxxx>
> > 
> > There's no need to force the user to assign a vdev. We can automatically
> > assign one, starting at xvda and searching until we find the first disk
> > name that's unused.
> > 
> > This means we can now allow '-drive if=xen,file=xxx' to work without an
> > explicit separate -driver argument, just like if=virtio.
> > 
> > Signed-off-by: David Woodhouse <dwmw@xxxxxxxxxxxx>
> 
> Actually, how does this play together with xen_config_dev_blk()? This
> looks like it tried to implement a very similar thing (which is IF_XEN
> even already existed).
> 
> Are we now trying to attach each if=xen disk twice in the 'xenpv'
> machine? Or if something prevents this, is it dead code?
> 
> I think in both cases, we would want to delete that function and remove
> the loop that calls it in xen_init_pv()?

I tested this with an xl config which looks a bit like this...

disk = [ 
"backendtype=qdisk,format=qcow2,vdev=xvda,access=rw,target=/var/lib/libvirt/images/fedora28.qcow2"
 ]
device_model_override = "/home/dwmw2/git/qemu/build/qemu-system-x86_64"
device_model_version = "qemu-xen"
device_model_args = [ 
"-trace","xen*","-chardev","pty,id=mon","-mon","mon","-drive","file=/var/lib/libvirt/images/solaris11.qcow2,format=qcow2,if=xen","-nic","user,model=xen"
 ]

The code in xen_config_dev_blk() scribbles over the disk that the
toolstack has configured for me, and adds that qcow2 file from the
'-drive' option on the command line, but in *raw* mode.

Then the new xen-disk support kicks in and finds a free vdev, and adds
the -drive properly /dev/xvdb (as qcow2).

So v2 of this patch will just rip out xen_config_dev_blk() as you
suggest.

Attachment: smime.p7s
Description: S/MIME cryptographic signature