Re: [PATCH V2 23/23] [RFC] libxl: Add support for virtio-disk configuration

[Oleksandr <olekstysh@xxxxxxxxx>]

On 11.11.20 06:28, Wei Chen wrote:
> Hi Oleksandr,
Hi Wei


> > > > An example of domain configuration (two disks are assigned to the guest,
> > > > the latter is in readonly mode):
> > > >
> > > > vdisk = [ 'backend=DomD, disks=rw:/dev/mmcblk0p3;ro:/dev/mmcblk1p3' ]
> > > Can we keep use the same 'disk' parameter for virtio-disk, but add an option
> > like
> > >    "model=virtio-disk"?
> > > For example:
> > > disk = [ 'backend=DomD, disks=rw:/dev/mmcblk0p3,model=virtio-disk' ]
> > > Just like what Xen has done for x86 virtio-net.
> > I think, this needs an additional investigation. In general I agree with
> > you that it would be nice to reuse existing 'disk' parameter somehow
> > rather than introducing new one
> > for the same purpose (to handle virtual block device(s)).
> >
> >
> > One note, although both are used for the same purpose they are different
> > in at least one important option.
> >
> > For example:
> > 1. disk = [ 'backend=DomD, phy:/dev/mmcblk0p3, xvda1' ]
> > 2. vdisk = [ 'backend=DomD, disks=rw:/dev/mmcblk0p3' ]
> > As you can see existing "disk" parameter contains xvda1, this means that
> > a new device /dev/xvda1 will appear at the guest side, but "vdisk"
> > doesn't contain anything similar. So with Xen PV driver (xen-blkfront)
> Yes, I understand your concerns. But I think specifying a device name
> for virtio disk is not a mandatory requirement. Even if we're using physical
> disks on bare metal machine, we can't guarantee slot#1 disk is always 'sda'.
> So most modern OS are prefer to use blkid to mount filesystem.
>
> > we are able to configure a device name, but with VirtIO solution
> > (virtio-blk) we aren't (at least I don't know how exactly).
> Just my understanding, not exactly accurate:
> The virtio-blk could not get VDEV information for a bus like Xen-bus. So the 
> disk
> ID is allocated dynamically in bus probe progress. The first probed disk will 
> get
> ID 'a'. And then the ID keeps increasing. If we want to specify the disk ID for 
> virtio
> disk, one possible way to do this is to construct a reasonable position on bus
> (fdt node position of virtio mmio device, PCI Function ID of virtio pci block) 
> for
> virtio disk. But it is not always successful, we can't skip 'vda' to specify a 
> virtio
> disk as 'vdb'.
Thank you for the explanation. I got your point regarding using the same 
disk parameter and I think it makes sense. Now I am focusing on IOREQ 
transport to be available on Arm, and after that (I hope)
I will be able to return to virtio stuff.

--
Regards,

Oleksandr Tyshchenko