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
