From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 909D932C8B for ; Fri, 6 Dec 2024 07:42:05 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1733470925; cv=none; b=Z7rY409QfS5yGwUocb7lHqvXcT1uU7dGNnm1RcImSdDKNkwCvQcr4TrlUl7mBteNRHeECTOA8jQ9Gb1V0GMyWySsFEuiDXEJE4XTUsvCpSMII7srJOD3wZMmgrVyspmFoz3eNd9+dsUu/jvM+8XMPuN9vQF8COJ0ot+zu1EoDHA= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1733470925; c=relaxed/simple; bh=7xARTIKvWcEmKQKWvC+2KlJa7ZEWKl4pqVxp00Mg0pk=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=g/iYBJgSiyI/vmaYnoT1nrvkaC2E5RW822HWrXtKzW6SxrrT/oNReiw0exDhoCfUUUpZfeSHN/JcodvpLDaPh8fwyLvCtcEYFlf7+ZYs2xZSW3KHRHH9zUHCB8UXs80moAQv7lG1VvEMqDvAJzR6oeKG9cNPK8D1PtTPXJiVyt0= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linuxfoundation.org header.i=@linuxfoundation.org header.b=SQQCRUCV; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linuxfoundation.org header.i=@linuxfoundation.org header.b="SQQCRUCV" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 84639C4CED1; Fri, 6 Dec 2024 07:42:04 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1733470925; bh=7xARTIKvWcEmKQKWvC+2KlJa7ZEWKl4pqVxp00Mg0pk=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=SQQCRUCV2MkFFg7cqIQ+4SnnRPN56B0aCbhpinC/YkWrxYGPt0M1a+4F1kx0SYyTw CWE2l0C5/QxSx3INJ1cHBAir22KwNWTNNKeDfibKpy3cvguxDXnXISnhOfI82QALCC JLMp2xxQpLX/y8fSq3US1FMmhWUO2jo23SJ8EwF0= Date: Fri, 6 Dec 2024 08:42:02 +0100 From: Greg Kroah-Hartman To: Heiner Kallweit Cc: Alex Williamson , "Rafael J. Wysocki" , Kirti Wankhede , kvm@vger.kernel.org Subject: Re: [PATCH 2/3] vfio/mdev: inline needed class_compat functionality Message-ID: <2024120617-icon-bagel-86b3@gregkh> References: <147a2a3e-8227-4f1b-9ab4-d0b4f261d2a6@gmail.com> <0a14a4df-fbb5-4613-837f-f8025dc73380@gmail.com> <2024120430-boneless-wafer-bf0c@gregkh> <2024120410-promoter-blandness-efa1@gregkh> <20241204123040.7e3483a4.alex.williamson@redhat.com> <9015ce52-e4f3-459c-bd74-b8707cf8fd88@gmail.com> Precedence: bulk X-Mailing-List: kvm@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <9015ce52-e4f3-459c-bd74-b8707cf8fd88@gmail.com> On Fri, Dec 06, 2024 at 08:35:47AM +0100, Heiner Kallweit wrote: > On 04.12.2024 20:30, Alex Williamson wrote: > > On Wed, 4 Dec 2024 19:16:03 +0100 > > Greg Kroah-Hartman wrote: > > > >> On Wed, Dec 04, 2024 at 06:01:36PM +0100, Heiner Kallweit wrote: > >>> On 04.12.2024 10:32, Greg Kroah-Hartman wrote: > >>>> On Tue, Dec 03, 2024 at 09:11:47PM +0100, Heiner Kallweit wrote: > >>>>> vfio/mdev is the last user of class_compat, and it doesn't use it for > >>>>> the intended purpose. See kdoc of class_compat_register(): > >>>>> Compatibility class are meant as a temporary user-space compatibility > >>>>> workaround when converting a family of class devices to a bus devices. > >>>> > >>>> True, so waht is mdev doing here? > >>>> > >>>>> In addition it uses only a part of the class_compat functionality. > >>>>> So inline the needed functionality, and afterwards all class_compat > >>>>> code can be removed. > >>>>> > >>>>> No functional change intended. Compile-tested only. > >>>>> > >>>>> Signed-off-by: Heiner Kallweit > >>>>> --- > >>>>> drivers/vfio/mdev/mdev_core.c | 12 ++++++------ > >>>>> 1 file changed, 6 insertions(+), 6 deletions(-) > >>>>> > >>>>> diff --git a/drivers/vfio/mdev/mdev_core.c b/drivers/vfio/mdev/mdev_core.c > >>>>> index ed4737de4..a22c49804 100644 > >>>>> --- a/drivers/vfio/mdev/mdev_core.c > >>>>> +++ b/drivers/vfio/mdev/mdev_core.c > >>>>> @@ -18,7 +18,7 @@ > >>>>> #define DRIVER_AUTHOR "NVIDIA Corporation" > >>>>> #define DRIVER_DESC "Mediated device Core Driver" > >>>>> > >>>>> -static struct class_compat *mdev_bus_compat_class; > >>>>> +static struct kobject *mdev_bus_kobj; > >>>> > >>>> > >>>> > >>>>> > >>>>> static LIST_HEAD(mdev_list); > >>>>> static DEFINE_MUTEX(mdev_list_lock); > >>>>> @@ -76,7 +76,7 @@ int mdev_register_parent(struct mdev_parent *parent, struct device *dev, > >>>>> if (ret) > >>>>> return ret; > >>>>> > >>>>> - ret = class_compat_create_link(mdev_bus_compat_class, dev, NULL); > >>>>> + ret = sysfs_create_link(mdev_bus_kobj, &dev->kobj, dev_name(dev)); > >>>> > >>>> This feels really wrong, why create a link to a random kobject? Who is > >>>> using this kobject link? > >>>> > >>>>> if (ret) > >>>>> dev_warn(dev, "Failed to create compatibility class link\n"); > >>>>> > >>>>> @@ -98,7 +98,7 @@ void mdev_unregister_parent(struct mdev_parent *parent) > >>>>> dev_info(parent->dev, "MDEV: Unregistering\n"); > >>>>> > >>>>> down_write(&parent->unreg_sem); > >>>>> - class_compat_remove_link(mdev_bus_compat_class, parent->dev, NULL); > >>>>> + sysfs_remove_link(mdev_bus_kobj, dev_name(parent->dev)); > >>>>> device_for_each_child(parent->dev, NULL, mdev_device_remove_cb); > >>>>> parent_remove_sysfs_files(parent); > >>>>> up_write(&parent->unreg_sem); > >>>>> @@ -251,8 +251,8 @@ static int __init mdev_init(void) > >>>>> if (ret) > >>>>> return ret; > >>>>> > >>>>> - mdev_bus_compat_class = class_compat_register("mdev_bus"); > >>>>> - if (!mdev_bus_compat_class) { > >>>>> + mdev_bus_kobj = class_pseudo_register("mdev_bus"); > >>>> > >>>> But this isn't a class, so let's not fake it please. Let's fix this > >>>> properly, odds are all of this code can just be removed entirely, right? > >>>> > >>> > >>> After I removed class_compat from i2c core, I asked Alex basically the > >>> same thing: whether class_compat support can be removed from vfio/mdev too. > >>> > >>> His reply: > >>> I'm afraid we have active userspace tools dependent on > >>> /sys/class/mdev_bus currently, libvirt for one. We link mdev parent > >>> devices here and I believe it's the only way for userspace to find > >>> those parent devices registered for creating mdev devices. If there's a > >>> desire to remove class_compat, we might need to add some mdev > >>> infrastructure to register the class ourselves to maintain the parent > >>> links. > >>> > >>> > >>> It's my understanding that /sys/class/mdev_bus has nothing in common > >>> with an actual class, it's just a container for devices which at least > >>> partially belong to other classes. And there's user space tools depending > >>> on this structure. > >> > >> That's odd, when this was added, why was it added this way? The > >> class_compat stuff is for when classes move around, yet this was always > >> done in this way? > >> > >> And what tools use this symlink today that can't be updated? > > > > It's been this way for 8 years, so it's hard to remember exact > > motivation for using this mechanism, whether we just didn't look hard > > enough at the class_compat or it didn't pass by the right set of eyes. > > Yes, it's always been this way for the mdev_bus class. > > > > The intention here is much like other classes, that we have a node in > > sysfs where we can find devices that provide a common feature, in this > > case providing support for creating and managing vfio mediated devices > > (mdevs). The perhaps unique part of this use case is that these devices > > aren't strictly mdev providers, they might also belong to another class > > and the mdev aspect of their behavior might be dynamically added after > > the device itself is added. > > > > I've done some testing with this series and it does indeed seem to > > maintain compatibility with existing userspace tools, mdevctl and > > libvirt. We can update these tools, but then we get into the breaking > > Greg, is this testing, done by Alex, sufficient for you to take the series? Were devices actually removed from the system and all worked well? > > userspace and deprecation period questions, where we may further delay > > removal of class_compat. Also if we were to re-implement this, is there > > a better mechanism than proposed here within the class hierarchy, or > > would you recommend a non-class approach? Thanks, > > > > You have /sys/bus/mdev. Couldn't we create a directory here which holds > the links to the devices in question? Links to devices is not what class links are for, so why is this in /sys/class/ at all? > Then user space would simply have to switch from /sys/class/mdev_bus > to /sys/bus/mdev/. I think you are confusing what /sys/class/ is for here, if you have devices on a "bus" then they need to be in /sys/bus/ class has nothing to do with that. So can we just drop the /sys/class/ mistake entirely? thanks, greg k-h