Re: [libvirt] [Question] nodedev-list --cap return nothing after creating a mdev
Could you please share what the commit id is ?
Thanks,
Zongyong Wu
-----Original Message-----
From: Erik Skultety [mailto:eskultet@redhat.com]
Sent: Thursday, February 01, 2018 4:09 PM
To: Wuzongyong (Euler Dept) <cordius.wu(a)huawei.com>
Cc: Alex Williamson <alex.williamson(a)redhat.com>; libvir-list(a)redhat.com;
weijinfen <weijinfen(a)huawei.com>
Subject: Re: [libvirt][Question] nodedev-list --cap return nothing after
creating a mdev
On Thu, Feb 01, 2018 at 07:19:45AM +0000, Wuzongyong (Euler Dept) wrote:
> Hi,
>
> I meet a problem that libvirt handle new mediated devices wrongly.
> Command `virsh nodedev-list -cap mdev` return none after I create a mdev,
and the root cause I found is:
>
> // kernel code
> int mdev_device_create(struct kobject *kobj, struct device *dev,
> uuid_le uuid) { ...
> ret = device_register(&mdev->dev); // send udev event here --- 1
> if (ret) {
> put_device(&mdev->dev);
> goto create_err;
> }
>
> ret = mdev_device_create_ops(kobj, mdev);
> if (ret)
> goto create_failed;
>
> ret = mdev_create_sysfs_files(&mdev->dev, type); // create
mdev_type symbol link here --- 2
> if (ret) {
> mdev_device_remove_ops(mdev, true);
> goto create_failed;
> }
>
> mdev->type_kobj = kobj;
> dev_dbg(&mdev->dev, "MDEV: created\n"); ...
> }
>
> At point 1, kernel send a udev event(add). If libvirt receive this
> event and handle it before kernel code reach point 2, libvirt just fail
to resolve link such as
'/sys/devices/pci0000:80/0000:80:02.0/0000:81:00.0/36b79575-ada8-4406-
893d-8cfd8d10a984/mdev_type'
> because the link haven't been created yet. Then libvirt thinks this
devices doesn't exsit and stop tracking info of this device.
> Finally, command `vish nodedev-list -cap` return nothing though the
device exist at host indeed.
>
> To make it easy to reproduce this problem, I just add a `udelay(1)`
before point 2 by kprobe.
>
> So I think maybe we should add 'kobject_uevent(..., KOBJ_ADD)' after
point 2 instead of point 1 ?
> Or is there any other method to solve this problem?
Hi,
just a note, we worked around this in upstream libvirt already.
Thanks for the pointer though, I'd also be interested in possible
solutions in kernel.
Erik