2026年3月10日(火) 12:02 Jason Wang <[email protected]>: > > On Mon, Mar 9, 2026 at 2:19 PM Yui Washizu <[email protected]> wrote: > > > > > > On 3/9/2026 12:33 PM, Jason Wang wrote: > > > On Mon, Mar 9, 2026 at 10:37 AM Yui Washizu <[email protected]> wrote: > > >> Recent QEMU versions added support for virtio SR-IOV emulation, > > >> allowing virtio devices to expose SR-IOV VFs to the guest. > > >> However, virtio_bus does not implement the num_vf callback of bus_type, > > >> causing dev_num_vf() to return 0 for virtio devices even when > > >> SR-IOV VFs are active. > > >> > > >> net/core/rtnetlink.c calls dev_num_vf(dev->dev.parent) to populate > > >> IFLA_NUM_VF and IFLA_VFINFO_LIST > > > Patch looks good but, > > > > > > If I understand correctly, ndo_get_vf_config is needed for > > > IFLA_VFINFO_LIST but not implemeted in this patch? > > > > Thank you for your comment. > > > > I submitted this patch because I confirmed > > that "ip link show" returns the correct VF IDs with this implementation. > > > > In the current implementation, > > I believe there is no information that would need to be referenced > > through IFLA_VFINFO_LIST. > > Therefore, I did not include ndo_get_vf_config in this patch, > > as it did not seem essential at this stage. > > > > Would it be better to implement IFLA_VFINFO_LIST support together with this? > > Then it's not, I think it's better to not mention IFLA_VFINFO_LIST in > the commit log as it may confuse people. > > Thanks >
Thank you. I'll update the commit message to remove the reference to IFLA_VFINFO_LIST and send a v2. Regards, > > > > > Regards, > > > > > > >> in RTM_GETLINK responses. For a > > >> virtio-net device, dev.parent points to the virtio_device, whose bus > > >> is virtio_bus. Without num_vf, SR-IOV VF information is silently > > >> omitted from tools that rely on rtnetlink, such as 'ip link show'. > > >> > > >> Add a num_vf callback that delegates to dev_num_vf(dev->parent), > > >> which in turn reaches the underlying transport (pci_bus_type for > > >> virtio-pci) where the actual VF count is tracked. Non-PCI transports > > >> are unaffected as dev_num_vf() returns 0 when no num_vf callback is > > >> present. > > >> > > >> Signed-off-by: Yui Washizu <[email protected]> > > >> --- > > >> drivers/virtio/virtio.c | 9 +++++++++ > > >> 1 file changed, 9 insertions(+) > > >> > > >> diff --git a/drivers/virtio/virtio.c b/drivers/virtio/virtio.c > > >> index 5bdc6b82b30b..299fa83be1d5 100644 > > >> --- a/drivers/virtio/virtio.c > > >> +++ b/drivers/virtio/virtio.c > > >> @@ -435,6 +435,14 @@ static void virtio_dev_shutdown(struct device *_d) > > >> dev->config->reset(dev); > > >> } > > >> > > >> +static int virtio_dev_num_vf(struct device *dev) > > >> +{ > > >> + struct virtio_device *vdev = dev_to_virtio(dev); > > >> + > > >> + return dev_num_vf(vdev->dev.parent); > > >> +} > > >> + > > >> + > > >> static const struct bus_type virtio_bus = { > > >> .name = "virtio", > > >> .match = virtio_dev_match, > > >> @@ -444,6 +452,7 @@ static const struct bus_type virtio_bus = { > > >> .remove = virtio_dev_remove, > > >> .irq_get_affinity = virtio_irq_get_affinity, > > >> .shutdown = virtio_dev_shutdown, > > >> + .num_vf = virtio_dev_num_vf, > > >> }; > > >> > > >> int __register_virtio_driver(struct virtio_driver *driver, struct > > >> module *owner) > > >> -- > > >> 2.47.3 > > >> > > > Thanks > > > > > >
