[libvirt] [Question] nodedev-list --cap return nothing after creating a mdev

[Wuzongyong (Euler Dept)]

> On Thu, Feb 01, 2018 at 12:03:42PM +0000, Wuzongyong (Euler Dept) wrote:
> > a mdev
> > >
> > > On Thu, Feb 01, 2018 at 09:08:59AM +0000, Wuzongyong (Euler Dept)
> wrote:
> > > > Hi,
> > > >
> > > > I solve this problem by sending a CHANGE event to userspace after
> > > creating the symbol link like sriov driver.
> > > >
> > > > diff --git a/drivers/vfio/mdev/mdev_core.c
> > > > b/drivers/vfio/mdev/mdev_core.c index 1269910..a23f1d7 100644
> > > > --- a/drivers/vfio/mdev/mdev_core.c
> > > > +++ b/drivers/vfio/mdev/mdev_core.c
> > > > @@ -351,6 +351,8 @@ int mdev_device_create(struct kobject *kobj,
> > > > struct
> > > device *dev, uuid_le uuid)
> > > >                 goto create_failed;
> > > >         }
> > > >
> > > > +        kobject_uevent(&(mdev->dev.kobj), KOBJ_CHANGE);
> > > > +
> > > >         mdev->type_kobj = kobj;
> > > >         dev_dbg(&mdev->dev, "MDEV: created\n");
> > > >
> > > > Is this patch ok?
> > >
> > > I'm not really familiar with kernel, but from a layman's point of
> > > view, the ADD and CHANGE event should be clearly distinguished, but
> > > here you expect the CHANGE event to be the result of creating the
> > > sysfs entry, whereas in general you'd expect this from the ADD
> > > event, since it's really the object has just been created for the
> first time, right?
> > >
> > > Erik
> > >
> >
> > The ADD event has been sended before sending CHANGE event. And before
> > sending ADD event, the mdev sysfs file node and some general attribute
> > such as power/uevent has been created, but the mdev_type file(link
> > libvirt want to resolve) has not been created yet. So I think maybe we
> > should send a CHANGE event to tell libvirt this link has been created so
> libvirt can resolve it correctly.
> 
> Well, as much beneficial as getting an event from udev can be, it wouldn't
> change anything within libvirt really, since when we get the ADD event, we
> try to wait for the link to appear and only then continue. With the CHANGE
> event we'll update the device again. I'm only saying it because we'll be
> supporting running upstream on kernels prior to this potential change/fix,
> so it will take "a few" years until libvirt is going to solely rely on
> udev events here.
> 
> The commit ID you asked in the other mail is 1af45804.
> 
> Erik

Yes, you are right. I forgot to take the case that kernels prior to this potential change into account.

Thanks,
Zongyong Wu