Re: [Qemu-devel] [PATCH 13/13] qdev-properties: Add pci-devaddr property

["Michael S. Tsirkin" <mst@redhat.com>]

On Sun, Jun 10, 2012 at 07:41:51AM -0600, Alex Williamson wrote:
> > > >>>> vfio_pci.c contains a nice function called "parse_hostaddr". You may
> > > >>>> guess what it does. ;)
> > > >>>
> > > >>> Interesting. Why? This looks strange to me:
> > > >>> I would expect the admin to bind a device to vfio
> > > >>> the way it's now bound to a stub.
> > > >>> The pass /dev/vfioXXX to qemu.
> > > >>
> > > >> That's the "libvirt way". We surely also want the "qemu command line
> > > >> way" for which this kind of service is needed.
> > > >>
> > > >> Jan
> > > >>
> > > > 
> > > > Yes, I imagine the qemu command line passing in /dev/vfioXXX,
> > > > the libvirt way will pass in an fd for above. No?
> > > 
> > > As far as I understand the API, there is no device file per assigned
> > > device.
> > 
> > Does it do pci_get_domain_bus_and_slot like kvm then?
> > With all the warts like you have to remember to bind pci stub
> > or you get two drivers for one device?
> > If true that's unfortunate IMHO.

I hope the answer to the above is no?

> > > Also, this [domain:]bus:dev.fn format is more handy for the
> > > command line.
> > > 
> > > Jan
> > > 
> > 
> > Then users could add udev rules that will name vfio devices
> > like this.  Another interesting option: /dev/vfio/eth0/vf1.
> > That's better I think: no one really likes running lspci
> > and guessing the address from there.
> 
> That's not at all how VFIO works.  /dev/vfio/# represents a group, which
> may contain one or more devices.  Even if libvirt passes a file
> descriptor for the group, qemu needs to know which device in the group
> to add to the guest, so parsing a device address is still necessary.
> Thanks,
> 
> Alex

That's very unusual, and unfortunate.  For example this means that I
must update applications just because I move a card to another slot.
UIO does not have this problem.
The fact that it's broken in kvm ATM seems to have made people
think it's okay, but it really is a bug. We didn't fix it
because vfio was supposed to be the solution.

I do realize you want to represent a group of devices somehow but can't
this be solved without breaking naming devices with udev? For example, the
device could be a file as well. You would then use the fd to identify the
device within the group. And in a somewhat common case of a single device
within the group, you can even make opening the group optional.
Don't know if this fix I suggest makes sense at all but it's a real
problem all the same.

-- 
MST