(click the wrong reply button again, sorry) On Thu, Apr 5, 2018 at 8:31 AM, Paolo Bonzini <pbonzini@xxxxxxxxxx> wrote: > On 04/04/2018 10:02, Siwei Liu wrote: >>> pci_bus_num is almost always a bug if not done within >>> a context of a PCI host, bridge, etc. >>> >>> In particular this will not DTRT if run before guest assigns bus >>> numbers. >>> >> I was seeking means to reserve a specific pci bus slot from drivers, >> and update the driver when guest assigns the bus number but it seems >> there's no low-hanging fruits. Because of that reason the bus_num is >> only obtained until it's really needed (during get_config) and I >> assume at that point the pci bus assignment is already done. I know >> the current one is not perfect, but we need that information (PCI >> bus:slot.func number) to name the guest device correctly. > > Can you use the -device "id", and look it up as > > devices = container_get(qdev_get_machine(), "/peripheral"); > return object_resolve_path_component(devices, id); No. The problem of using device id is that the vfio device may come and go at any time, this is particularly true when live migration is happening. There's no gurantee we can get the bus:device.func info if that device is gone. Currently the binding between vfio and virtio-net is weakly coupled through the backup property, there's no better way than specifying the bus id and addr property directly. Regards, -Siwei > > ? > > Thanks, > > Paolo _______________________________________________ Virtualization mailing list Virtualization@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linuxfoundation.org/mailman/listinfo/virtualization
