* [PATCH 0/2] vfio: Deprecate fsl-mc, platform, and amba
@ 2025-08-06 17:03 Alex Williamson
2025-08-06 17:03 ` [PATCH 1/2] vfio/fsl-mc: Mark for removal Alex Williamson
` (4 more replies)
0 siblings, 5 replies; 18+ messages in thread
From: Alex Williamson @ 2025-08-06 17:03 UTC (permalink / raw)
To: alex.williamson, kvm; +Cc: linux-kernel, eric.auger, clg
The vfio-fsl-mc driver has been orphaned since April 2024 after the
maintainer became unresponsive. More than a year later, the driver
has only received community maintenance. Let's take the next step
towards removal by marking it obsolete/deprecated.
The vfio-platform and vfio-amba drivers have an active maintainer,
but even the maintainer has no ability to test these drivers anymore.
The hardware itself has become obsolete and despite Eric's efforts to
add support for new devices and presenting on the complexities of
trying to manage and support shared resources at KVM Forum 2024, the
state of the driver and ability to test it upstream has not advanced.
The experiment has been useful, but seems to be reaching a conclusion.
QEMU intends to remove vfio-platform support in the 10.2 release.
Mark these drivers as obsolete/deprecated in the kernel as well.
Thanks,
Alex
Alex Williamson (2):
vfio/fsl-mc: Mark for removal
vfio/platform: Mark for removal
MAINTAINERS | 4 ++--
drivers/vfio/fsl-mc/Kconfig | 5 ++++-
drivers/vfio/fsl-mc/vfio_fsl_mc.c | 2 ++
drivers/vfio/platform/Kconfig | 10 ++++++++--
drivers/vfio/platform/reset/Kconfig | 6 +++---
drivers/vfio/platform/vfio_amba.c | 2 ++
drivers/vfio/platform/vfio_platform.c | 2 ++
7 files changed, 23 insertions(+), 8 deletions(-)
--
2.50.1
^ permalink raw reply [flat|nested] 18+ messages in thread* [PATCH 1/2] vfio/fsl-mc: Mark for removal 2025-08-06 17:03 [PATCH 0/2] vfio: Deprecate fsl-mc, platform, and amba Alex Williamson @ 2025-08-06 17:03 ` Alex Williamson 2025-08-15 10:02 ` Tian, Kevin 2025-08-06 17:03 ` [PATCH 2/2] vfio/platform: " Alex Williamson ` (3 subsequent siblings) 4 siblings, 1 reply; 18+ messages in thread From: Alex Williamson @ 2025-08-06 17:03 UTC (permalink / raw) To: alex.williamson, kvm; +Cc: linux-kernel, eric.auger, clg The driver has been orphaned for more than a year, mark it for removal. Signed-off-by: Alex Williamson <alex.williamson@redhat.com> --- MAINTAINERS | 2 +- drivers/vfio/fsl-mc/Kconfig | 5 ++++- drivers/vfio/fsl-mc/vfio_fsl_mc.c | 2 ++ 3 files changed, 7 insertions(+), 2 deletions(-) diff --git a/MAINTAINERS b/MAINTAINERS index c0b444e5fd5a..25a520467dec 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -26033,7 +26033,7 @@ F: include/uapi/linux/vfio.h VFIO FSL-MC DRIVER L: kvm@vger.kernel.org -S: Orphan +S: Obsolete F: drivers/vfio/fsl-mc/ VFIO HISILICON PCI DRIVER diff --git a/drivers/vfio/fsl-mc/Kconfig b/drivers/vfio/fsl-mc/Kconfig index 7d1d690348f0..43c145d17971 100644 --- a/drivers/vfio/fsl-mc/Kconfig +++ b/drivers/vfio/fsl-mc/Kconfig @@ -2,9 +2,12 @@ menu "VFIO support for FSL_MC bus devices" depends on FSL_MC_BUS config VFIO_FSL_MC - tristate "VFIO support for QorIQ DPAA2 fsl-mc bus devices" + tristate "VFIO support for QorIQ DPAA2 fsl-mc bus devices (DEPRECATED)" select EVENTFD help + The vfio-fsl-mc driver is deprecated and will be removed in a + future kernel release. + Driver to enable support for the VFIO QorIQ DPAA2 fsl-mc (Management Complex) devices. This is required to passthrough fsl-mc bus devices using the VFIO framework. diff --git a/drivers/vfio/fsl-mc/vfio_fsl_mc.c b/drivers/vfio/fsl-mc/vfio_fsl_mc.c index f65d91c01f2e..76ccbab0e3d6 100644 --- a/drivers/vfio/fsl-mc/vfio_fsl_mc.c +++ b/drivers/vfio/fsl-mc/vfio_fsl_mc.c @@ -537,6 +537,8 @@ static int vfio_fsl_mc_probe(struct fsl_mc_device *mc_dev) struct device *dev = &mc_dev->dev; int ret; + dev_err_once(dev, "DEPRECATION: vfio-fsl-mc is deprecated and will be removed in a future kernel release\n"); + vdev = vfio_alloc_device(vfio_fsl_mc_device, vdev, dev, &vfio_fsl_mc_ops); if (IS_ERR(vdev)) -- 2.50.1 ^ permalink raw reply related [flat|nested] 18+ messages in thread
* RE: [PATCH 1/2] vfio/fsl-mc: Mark for removal 2025-08-06 17:03 ` [PATCH 1/2] vfio/fsl-mc: Mark for removal Alex Williamson @ 2025-08-15 10:02 ` Tian, Kevin 0 siblings, 0 replies; 18+ messages in thread From: Tian, Kevin @ 2025-08-15 10:02 UTC (permalink / raw) To: Alex Williamson, kvm@vger.kernel.org Cc: linux-kernel@vger.kernel.org, eric.auger@redhat.com, clg@redhat.com > From: Alex Williamson <alex.williamson@redhat.com> > Sent: Thursday, August 7, 2025 1:03 AM > > The driver has been orphaned for more than a year, mark it for removal. > > Signed-off-by: Alex Williamson <alex.williamson@redhat.com> Reviewed-by: Kevin Tian <kevin.tian@intel.com> ^ permalink raw reply [flat|nested] 18+ messages in thread
* [PATCH 2/2] vfio/platform: Mark for removal 2025-08-06 17:03 [PATCH 0/2] vfio: Deprecate fsl-mc, platform, and amba Alex Williamson 2025-08-06 17:03 ` [PATCH 1/2] vfio/fsl-mc: Mark for removal Alex Williamson @ 2025-08-06 17:03 ` Alex Williamson 2025-08-15 10:02 ` Tian, Kevin 2025-08-15 16:59 ` Mostafa Saleh 2025-08-07 8:12 ` [PATCH 0/2] vfio: Deprecate fsl-mc, platform, and amba Eric Auger ` (2 subsequent siblings) 4 siblings, 2 replies; 18+ messages in thread From: Alex Williamson @ 2025-08-06 17:03 UTC (permalink / raw) To: alex.williamson, kvm; +Cc: linux-kernel, eric.auger, clg vfio-platform hasn't had a meaningful contribution in years. In-tree hardware support is predominantly only for devices which are long since e-waste. QEMU support for platform devices is slated for removal in QEMU-10.2. Eric Auger presented on the future of the vfio-platform driver and difficulties supporting new devices at KVM Forum 2024, gaining some support for removal, some disagreement, but garnering no new hardware support, leaving the driver in a state where it cannot be tested. Mark as obsolete and subject to removal. Link: https://lore.kernel.org/all/20250731121947.1346927-1-clg@redhat.com/ Link: https://www.youtube.com/watch?v=Q5BOSbtwRr8 Signed-off-by: Alex Williamson <alex.williamson@redhat.com> --- MAINTAINERS | 2 +- drivers/vfio/platform/Kconfig | 10 ++++++++-- drivers/vfio/platform/reset/Kconfig | 6 +++--- drivers/vfio/platform/vfio_amba.c | 2 ++ drivers/vfio/platform/vfio_platform.c | 2 ++ 5 files changed, 16 insertions(+), 6 deletions(-) diff --git a/MAINTAINERS b/MAINTAINERS index 25a520467dec..c19b60032aa3 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -26084,7 +26084,7 @@ F: drivers/vfio/pci/pds/ VFIO PLATFORM DRIVER M: Eric Auger <eric.auger@redhat.com> L: kvm@vger.kernel.org -S: Maintained +S: Obsolete F: drivers/vfio/platform/ VFIO QAT PCI DRIVER diff --git a/drivers/vfio/platform/Kconfig b/drivers/vfio/platform/Kconfig index 88fcde51f024..a8bde833e9e5 100644 --- a/drivers/vfio/platform/Kconfig +++ b/drivers/vfio/platform/Kconfig @@ -7,9 +7,12 @@ config VFIO_PLATFORM_BASE select VFIO_VIRQFD config VFIO_PLATFORM - tristate "Generic VFIO support for any platform device" + tristate "Generic VFIO support for any platform device (DEPRECATED)" select VFIO_PLATFORM_BASE help + The vfio-platform driver is deprecated and will be removed in a + future kernel release. + Support for platform devices with VFIO. This is required to make use of platform devices present on the system using the VFIO framework. @@ -17,10 +20,13 @@ config VFIO_PLATFORM If you don't know what to do here, say N. config VFIO_AMBA - tristate "VFIO support for AMBA devices" + tristate "VFIO support for AMBA devices (DEPRECATED)" depends on ARM_AMBA || COMPILE_TEST select VFIO_PLATFORM_BASE help + The vfio-amba driver is deprecated and will be removed in a + future kernel release. + Support for ARM AMBA devices with VFIO. This is required to make use of ARM AMBA devices present on the system using the VFIO framework. diff --git a/drivers/vfio/platform/reset/Kconfig b/drivers/vfio/platform/reset/Kconfig index dcc08dc145a5..70af0dbe293b 100644 --- a/drivers/vfio/platform/reset/Kconfig +++ b/drivers/vfio/platform/reset/Kconfig @@ -1,21 +1,21 @@ # SPDX-License-Identifier: GPL-2.0-only if VFIO_PLATFORM config VFIO_PLATFORM_CALXEDAXGMAC_RESET - tristate "VFIO support for calxeda xgmac reset" + tristate "VFIO support for calxeda xgmac reset (DEPRECATED)" help Enables the VFIO platform driver to handle reset for Calxeda xgmac If you don't know what to do here, say N. config VFIO_PLATFORM_AMDXGBE_RESET - tristate "VFIO support for AMD XGBE reset" + tristate "VFIO support for AMD XGBE reset (DEPRECATED)" help Enables the VFIO platform driver to handle reset for AMD XGBE If you don't know what to do here, say N. config VFIO_PLATFORM_BCMFLEXRM_RESET - tristate "VFIO support for Broadcom FlexRM reset" + tristate "VFIO support for Broadcom FlexRM reset (DEPRECATED)" depends on ARCH_BCM_IPROC || COMPILE_TEST default ARCH_BCM_IPROC help diff --git a/drivers/vfio/platform/vfio_amba.c b/drivers/vfio/platform/vfio_amba.c index ff8ff8480968..9f5c527baa8a 100644 --- a/drivers/vfio/platform/vfio_amba.c +++ b/drivers/vfio/platform/vfio_amba.c @@ -70,6 +70,8 @@ static int vfio_amba_probe(struct amba_device *adev, const struct amba_id *id) struct vfio_platform_device *vdev; int ret; + dev_err_once(&adev->dev, "DEPRECATION: vfio-amba is deprecated and will be removed in a future kernel release\n"); + vdev = vfio_alloc_device(vfio_platform_device, vdev, &adev->dev, &vfio_amba_ops); if (IS_ERR(vdev)) diff --git a/drivers/vfio/platform/vfio_platform.c b/drivers/vfio/platform/vfio_platform.c index 512533501eb7..48a49b14164a 100644 --- a/drivers/vfio/platform/vfio_platform.c +++ b/drivers/vfio/platform/vfio_platform.c @@ -59,6 +59,8 @@ static int vfio_platform_probe(struct platform_device *pdev) struct vfio_platform_device *vdev; int ret; + dev_err_once(&pdev->dev, "DEPRECATION: vfio-platform is deprecated and will be removed in a future kernel release\n"); + vdev = vfio_alloc_device(vfio_platform_device, vdev, &pdev->dev, &vfio_platform_ops); if (IS_ERR(vdev)) -- 2.50.1 ^ permalink raw reply related [flat|nested] 18+ messages in thread
* RE: [PATCH 2/2] vfio/platform: Mark for removal 2025-08-06 17:03 ` [PATCH 2/2] vfio/platform: " Alex Williamson @ 2025-08-15 10:02 ` Tian, Kevin 2025-08-15 16:59 ` Mostafa Saleh 1 sibling, 0 replies; 18+ messages in thread From: Tian, Kevin @ 2025-08-15 10:02 UTC (permalink / raw) To: Alex Williamson, kvm@vger.kernel.org Cc: linux-kernel@vger.kernel.org, eric.auger@redhat.com, clg@redhat.com > From: Alex Williamson <alex.williamson@redhat.com> > Sent: Thursday, August 7, 2025 1:03 AM > > vfio-platform hasn't had a meaningful contribution in years. In-tree > hardware support is predominantly only for devices which are long since > e-waste. QEMU support for platform devices is slated for removal in > QEMU-10.2. Eric Auger presented on the future of the vfio-platform > driver and difficulties supporting new devices at KVM Forum 2024, > gaining some support for removal, some disagreement, but garnering no > new hardware support, leaving the driver in a state where it cannot > be tested. > > Mark as obsolete and subject to removal. > > Link: https://lore.kernel.org/all/20250731121947.1346927-1- > clg@redhat.com/ > Link: https://www.youtube.com/watch?v=Q5BOSbtwRr8 > Signed-off-by: Alex Williamson <alex.williamson@redhat.com> Reviewed-by: Kevin Tian <kevin.tian@intel.com> ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [PATCH 2/2] vfio/platform: Mark for removal 2025-08-06 17:03 ` [PATCH 2/2] vfio/platform: " Alex Williamson 2025-08-15 10:02 ` Tian, Kevin @ 2025-08-15 16:59 ` Mostafa Saleh 2025-08-18 16:52 ` Alex Williamson 1 sibling, 1 reply; 18+ messages in thread From: Mostafa Saleh @ 2025-08-15 16:59 UTC (permalink / raw) To: Alex Williamson; +Cc: kvm, linux-kernel, eric.auger, clg Hi Alex, On Wed, Aug 06, 2025 at 11:03:12AM -0600, Alex Williamson wrote: > vfio-platform hasn't had a meaningful contribution in years. In-tree > hardware support is predominantly only for devices which are long since > e-waste. QEMU support for platform devices is slated for removal in > QEMU-10.2. Eric Auger presented on the future of the vfio-platform > driver and difficulties supporting new devices at KVM Forum 2024, > gaining some support for removal, some disagreement, but garnering no > new hardware support, leaving the driver in a state where it cannot > be tested. > > Mark as obsolete and subject to removal. Recently(this year) in Android, we enabled VFIO-platform for protected KVM, and it’s supported in our VMM (CrosVM) [1]. CrosVM support is different from Qemu, as it doesn't require any device specific logic in the VMM, however, it relies on loading a device tree template in runtime (with “compatiable” string...) and it will just override regs, irqs.. So it doesn’t need device knowledge (at least for now) Similarly, the kernel doesn’t need reset drivers as the hypervisor handles that. Unfortunately, there is no upstream support at the moment, we are making some -slow- progress on that [2][3] If it helps, I have access to HW that can run that and I can review/test changes, until upstream support lands; if you are open to keeping VFIO-platform. Or I can look into adding support for existing upstream HW(with platforms I am familiar with as Pixel-6) Thanks, Mostafa [1] https://chromium.googlesource.com/chromiumos/platform/crosvm/+/refs/heads/chromeos/devices/src/platform/vfio_platform.rs [2] https://lore.kernel.org/linux-iommu/20250728175316.3706196-1-smostafa@google.com/ [3] https://lore.kernel.org/all/20250729225455.670324-1-seanjc@google.com/ > > Link: https://lore.kernel.org/all/20250731121947.1346927-1-clg@redhat.com/ > Link: https://www.youtube.com/watch?v=Q5BOSbtwRr8 > Signed-off-by: Alex Williamson <alex.williamson@redhat.com> > --- > MAINTAINERS | 2 +- > drivers/vfio/platform/Kconfig | 10 ++++++++-- > drivers/vfio/platform/reset/Kconfig | 6 +++--- > drivers/vfio/platform/vfio_amba.c | 2 ++ > drivers/vfio/platform/vfio_platform.c | 2 ++ > 5 files changed, 16 insertions(+), 6 deletions(-) > > diff --git a/MAINTAINERS b/MAINTAINERS > index 25a520467dec..c19b60032aa3 100644 > --- a/MAINTAINERS > +++ b/MAINTAINERS > @@ -26084,7 +26084,7 @@ F: drivers/vfio/pci/pds/ > VFIO PLATFORM DRIVER > M: Eric Auger <eric.auger@redhat.com> > L: kvm@vger.kernel.org > -S: Maintained > +S: Obsolete > F: drivers/vfio/platform/ > > VFIO QAT PCI DRIVER > diff --git a/drivers/vfio/platform/Kconfig b/drivers/vfio/platform/Kconfig > index 88fcde51f024..a8bde833e9e5 100644 > --- a/drivers/vfio/platform/Kconfig > +++ b/drivers/vfio/platform/Kconfig > @@ -7,9 +7,12 @@ config VFIO_PLATFORM_BASE > select VFIO_VIRQFD > > config VFIO_PLATFORM > - tristate "Generic VFIO support for any platform device" > + tristate "Generic VFIO support for any platform device (DEPRECATED)" > select VFIO_PLATFORM_BASE > help > + The vfio-platform driver is deprecated and will be removed in a > + future kernel release. > + > Support for platform devices with VFIO. This is required to make > use of platform devices present on the system using the VFIO > framework. > @@ -17,10 +20,13 @@ config VFIO_PLATFORM > If you don't know what to do here, say N. > > config VFIO_AMBA > - tristate "VFIO support for AMBA devices" > + tristate "VFIO support for AMBA devices (DEPRECATED)" > depends on ARM_AMBA || COMPILE_TEST > select VFIO_PLATFORM_BASE > help > + The vfio-amba driver is deprecated and will be removed in a > + future kernel release. > + > Support for ARM AMBA devices with VFIO. This is required to make > use of ARM AMBA devices present on the system using the VFIO > framework. > diff --git a/drivers/vfio/platform/reset/Kconfig b/drivers/vfio/platform/reset/Kconfig > index dcc08dc145a5..70af0dbe293b 100644 > --- a/drivers/vfio/platform/reset/Kconfig > +++ b/drivers/vfio/platform/reset/Kconfig > @@ -1,21 +1,21 @@ > # SPDX-License-Identifier: GPL-2.0-only > if VFIO_PLATFORM > config VFIO_PLATFORM_CALXEDAXGMAC_RESET > - tristate "VFIO support for calxeda xgmac reset" > + tristate "VFIO support for calxeda xgmac reset (DEPRECATED)" > help > Enables the VFIO platform driver to handle reset for Calxeda xgmac > > If you don't know what to do here, say N. > > config VFIO_PLATFORM_AMDXGBE_RESET > - tristate "VFIO support for AMD XGBE reset" > + tristate "VFIO support for AMD XGBE reset (DEPRECATED)" > help > Enables the VFIO platform driver to handle reset for AMD XGBE > > If you don't know what to do here, say N. > > config VFIO_PLATFORM_BCMFLEXRM_RESET > - tristate "VFIO support for Broadcom FlexRM reset" > + tristate "VFIO support for Broadcom FlexRM reset (DEPRECATED)" > depends on ARCH_BCM_IPROC || COMPILE_TEST > default ARCH_BCM_IPROC > help > diff --git a/drivers/vfio/platform/vfio_amba.c b/drivers/vfio/platform/vfio_amba.c > index ff8ff8480968..9f5c527baa8a 100644 > --- a/drivers/vfio/platform/vfio_amba.c > +++ b/drivers/vfio/platform/vfio_amba.c > @@ -70,6 +70,8 @@ static int vfio_amba_probe(struct amba_device *adev, const struct amba_id *id) > struct vfio_platform_device *vdev; > int ret; > > + dev_err_once(&adev->dev, "DEPRECATION: vfio-amba is deprecated and will be removed in a future kernel release\n"); > + > vdev = vfio_alloc_device(vfio_platform_device, vdev, &adev->dev, > &vfio_amba_ops); > if (IS_ERR(vdev)) > diff --git a/drivers/vfio/platform/vfio_platform.c b/drivers/vfio/platform/vfio_platform.c > index 512533501eb7..48a49b14164a 100644 > --- a/drivers/vfio/platform/vfio_platform.c > +++ b/drivers/vfio/platform/vfio_platform.c > @@ -59,6 +59,8 @@ static int vfio_platform_probe(struct platform_device *pdev) > struct vfio_platform_device *vdev; > int ret; > > + dev_err_once(&pdev->dev, "DEPRECATION: vfio-platform is deprecated and will be removed in a future kernel release\n"); > + > vdev = vfio_alloc_device(vfio_platform_device, vdev, &pdev->dev, > &vfio_platform_ops); > if (IS_ERR(vdev)) > -- > 2.50.1 > ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [PATCH 2/2] vfio/platform: Mark for removal 2025-08-15 16:59 ` Mostafa Saleh @ 2025-08-18 16:52 ` Alex Williamson 2025-08-18 17:33 ` Mostafa Saleh 0 siblings, 1 reply; 18+ messages in thread From: Alex Williamson @ 2025-08-18 16:52 UTC (permalink / raw) To: Mostafa Saleh; +Cc: kvm, linux-kernel, eric.auger, clg On Fri, 15 Aug 2025 16:59:37 +0000 Mostafa Saleh <smostafa@google.com> wrote: > Hi Alex, > > On Wed, Aug 06, 2025 at 11:03:12AM -0600, Alex Williamson wrote: > > vfio-platform hasn't had a meaningful contribution in years. In-tree > > hardware support is predominantly only for devices which are long since > > e-waste. QEMU support for platform devices is slated for removal in > > QEMU-10.2. Eric Auger presented on the future of the vfio-platform > > driver and difficulties supporting new devices at KVM Forum 2024, > > gaining some support for removal, some disagreement, but garnering no > > new hardware support, leaving the driver in a state where it cannot > > be tested. > > > > Mark as obsolete and subject to removal. > > Recently(this year) in Android, we enabled VFIO-platform for protected KVM, > and it’s supported in our VMM (CrosVM) [1]. > CrosVM support is different from Qemu, as it doesn't require any device > specific logic in the VMM, however, it relies on loading a device tree > template in runtime (with “compatiable” string...) and it will just > override regs, irqs.. So it doesn’t need device knowledge (at least for now) > Similarly, the kernel doesn’t need reset drivers as the hypervisor handles that. I think what we attempt to achieve in vfio is repeatability and data integrity independent of the hypervisor. IOW, if we 'kill -9' the hypervisor process, the kernel can bring the device back to a default state where the device isn't wedged or leaking information through the device to the next use case. If the hypervisor wants to support enhanced resets on top of that, that's great, but I think it becomes difficult to argue that vfio-platform itself holds up its end of the bargain if we're really trusting the hypervisor to handle these aspects. > Unfortunately, there is no upstream support at the moment, we are making > some -slow- progress on that [2][3] > > If it helps, I have access to HW that can run that and I can review/test > changes, until upstream support lands; if you are open to keeping VFIO-platform. > Or I can look into adding support for existing upstream HW(with platforms I am > familiar with as Pixel-6) Ultimately I'll lean on Eric to make the call. I know he's concerned about testing, but he raised that and various other concerns whether platform device really have a future with vfio nearly a year ago and nothing has changed. Currently it requires a module option opt-in to enable devices that the kernel doesn't know how to reset. Is that sufficient or should use of such a device taint the kernel? If any device beyond the few e-waste devices that we know how to reset taint the kernel, should this support really even be in the kernel? Thanks, Alex ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [PATCH 2/2] vfio/platform: Mark for removal 2025-08-18 16:52 ` Alex Williamson @ 2025-08-18 17:33 ` Mostafa Saleh 2025-08-19 9:58 ` Eric Auger 0 siblings, 1 reply; 18+ messages in thread From: Mostafa Saleh @ 2025-08-18 17:33 UTC (permalink / raw) To: Alex Williamson; +Cc: kvm, linux-kernel, eric.auger, clg On Mon, Aug 18, 2025 at 10:52:42AM -0600, Alex Williamson wrote: > On Fri, 15 Aug 2025 16:59:37 +0000 > Mostafa Saleh <smostafa@google.com> wrote: > > > Hi Alex, > > > > On Wed, Aug 06, 2025 at 11:03:12AM -0600, Alex Williamson wrote: > > > vfio-platform hasn't had a meaningful contribution in years. In-tree > > > hardware support is predominantly only for devices which are long since > > > e-waste. QEMU support for platform devices is slated for removal in > > > QEMU-10.2. Eric Auger presented on the future of the vfio-platform > > > driver and difficulties supporting new devices at KVM Forum 2024, > > > gaining some support for removal, some disagreement, but garnering no > > > new hardware support, leaving the driver in a state where it cannot > > > be tested. > > > > > > Mark as obsolete and subject to removal. > > > > Recently(this year) in Android, we enabled VFIO-platform for protected KVM, > > and it’s supported in our VMM (CrosVM) [1]. > > CrosVM support is different from Qemu, as it doesn't require any device > > specific logic in the VMM, however, it relies on loading a device tree > > template in runtime (with “compatiable” string...) and it will just > > override regs, irqs.. So it doesn’t need device knowledge (at least for now) > > Similarly, the kernel doesn’t need reset drivers as the hypervisor handles that. > > I think what we attempt to achieve in vfio is repeatability and data > integrity independent of the hypervisor. IOW, if we 'kill -9' the > hypervisor process, the kernel can bring the device back to a default > state where the device isn't wedged or leaking information through the > device to the next use case. If the hypervisor wants to support > enhanced resets on top of that, that's great, but I think it becomes > difficult to argue that vfio-platform itself holds up its end of the > bargain if we're really trusting the hypervisor to handle these aspects. Sorry I was not clear, we only use that in Android for ARM64 and pKVM, where the hypervisor in this context means the code running in EL2 which is more privileged than the kernel, so it should be trusted. However, as I mentioned that code is not upstream yet, so it's a valid concern that the kernel still needs a reset driver. > > > Unfortunately, there is no upstream support at the moment, we are making > > some -slow- progress on that [2][3] > > > > If it helps, I have access to HW that can run that and I can review/test > > changes, until upstream support lands; if you are open to keeping VFIO-platform. > > Or I can look into adding support for existing upstream HW(with platforms I am > > familiar with as Pixel-6) > > Ultimately I'll lean on Eric to make the call. I know he's concerned > about testing, but he raised that and various other concerns whether > platform device really have a future with vfio nearly a year ago and > nothing has changed. Currently it requires a module option opt-in to > enable devices that the kernel doesn't know how to reset. Is that > sufficient or should use of such a device taint the kernel? If any > device beyond the few e-waste devices that we know how to reset taint > the kernel, should this support really even be in the kernel? Thanks, I think with the way it’s supported at the moment we need the kernel to ensure that reset happens. But maybe instead of having that specific reset handler for VFIO, we can rely on the “shutdown” method already existing in "platform_driver"? I believe that should put the device in a state where it can be re-probed safely. Although not all devices implement that but it seems more generic and scalable. Thanks, Mostafa > > Alex > ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [PATCH 2/2] vfio/platform: Mark for removal 2025-08-18 17:33 ` Mostafa Saleh @ 2025-08-19 9:58 ` Eric Auger 2025-08-20 15:20 ` Mostafa Saleh 0 siblings, 1 reply; 18+ messages in thread From: Eric Auger @ 2025-08-19 9:58 UTC (permalink / raw) To: Mostafa Saleh, Alex Williamson; +Cc: kvm, linux-kernel, clg Hi Mostafa, On 8/18/25 7:33 PM, Mostafa Saleh wrote: > On Mon, Aug 18, 2025 at 10:52:42AM -0600, Alex Williamson wrote: >> On Fri, 15 Aug 2025 16:59:37 +0000 >> Mostafa Saleh <smostafa@google.com> wrote: >> >>> Hi Alex, >>> >>> On Wed, Aug 06, 2025 at 11:03:12AM -0600, Alex Williamson wrote: >>>> vfio-platform hasn't had a meaningful contribution in years. In-tree >>>> hardware support is predominantly only for devices which are long since >>>> e-waste. QEMU support for platform devices is slated for removal in >>>> QEMU-10.2. Eric Auger presented on the future of the vfio-platform >>>> driver and difficulties supporting new devices at KVM Forum 2024, >>>> gaining some support for removal, some disagreement, but garnering no >>>> new hardware support, leaving the driver in a state where it cannot >>>> be tested. >>>> >>>> Mark as obsolete and subject to removal. >>> Recently(this year) in Android, we enabled VFIO-platform for protected KVM, >>> and it’s supported in our VMM (CrosVM) [1]. >>> CrosVM support is different from Qemu, as it doesn't require any device >>> specific logic in the VMM, however, it relies on loading a device tree >>> template in runtime (with “compatiable” string...) and it will just >>> override regs, irqs.. So it doesn’t need device knowledge (at least for now) >>> Similarly, the kernel doesn’t need reset drivers as the hypervisor handles that. >> I think what we attempt to achieve in vfio is repeatability and data >> integrity independent of the hypervisor. IOW, if we 'kill -9' the >> hypervisor process, the kernel can bring the device back to a default >> state where the device isn't wedged or leaking information through the >> device to the next use case. If the hypervisor wants to support >> enhanced resets on top of that, that's great, but I think it becomes >> difficult to argue that vfio-platform itself holds up its end of the >> bargain if we're really trusting the hypervisor to handle these aspects. > Sorry I was not clear, we only use that in Android for ARM64 and pKVM, > where the hypervisor in this context means the code running in EL2 which > is more privileged than the kernel, so it should be trusted. > However, as I mentioned that code is not upstream yet, so it's a valid > concern that the kernel still needs a reset driver. > >>> Unfortunately, there is no upstream support at the moment, we are making >>> some -slow- progress on that [2][3] >>> >>> If it helps, I have access to HW that can run that and I can review/test >>> changes, until upstream support lands; if you are open to keeping VFIO-platform. >>> Or I can look into adding support for existing upstream HW(with platforms I am >>> familiar with as Pixel-6) >> Ultimately I'll lean on Eric to make the call. I know he's concerned >> about testing, but he raised that and various other concerns whether >> platform device really have a future with vfio nearly a year ago and >> nothing has changed. Currently it requires a module option opt-in to >> enable devices that the kernel doesn't know how to reset. Is that >> sufficient or should use of such a device taint the kernel? If any >> device beyond the few e-waste devices that we know how to reset taint >> the kernel, should this support really even be in the kernel? Thanks, > I think with the way it’s supported at the moment we need the kernel > to ensure that reset happens. Effectively my main concern is I cannot test vfio-platform anymore. We had some CVEs also impacting the vfio platform code base and it is a major issue not being able to test. That's why I was obliged, last year, to resume the integration of a new device (the tegra234 mgbe), nobody seemed to be really interested in and this work could not be upstreamed due to lack of traction and its hacky nature. You did not really comment on which kind of devices were currently integrated. Are they within the original scope of vfio (with DMA capabilities and protected by an IOMMU)? Last discussion we had in https://lore.kernel.org/all/ZvvLpLUZnj-Z_tEs@google.com/ led to the conclusion that maybe VFIO was not the best suited framework. In case we keep the driver in, I think we need to get a garantee that you or someone else at Google commits to review and test potential changes with a perspective to take over its maintenance. Thanks Eric > > But maybe instead of having that specific reset handler for VFIO, we > can rely on the “shutdown” method already existing in "platform_driver"? > I believe that should put the device in a state where it can be re-probed > safely. Although not all devices implement that but it seems more generic > and scalable. > > Thanks, > Mostafa > >> Alex >> ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [PATCH 2/2] vfio/platform: Mark for removal 2025-08-19 9:58 ` Eric Auger @ 2025-08-20 15:20 ` Mostafa Saleh 2025-08-20 16:29 ` Eric Auger 0 siblings, 1 reply; 18+ messages in thread From: Mostafa Saleh @ 2025-08-20 15:20 UTC (permalink / raw) To: Eric Auger; +Cc: Alex Williamson, kvm, linux-kernel, clg Hi Eric, On Tue, Aug 19, 2025 at 11:58:32AM +0200, Eric Auger wrote: > Hi Mostafa, > > On 8/18/25 7:33 PM, Mostafa Saleh wrote: > > On Mon, Aug 18, 2025 at 10:52:42AM -0600, Alex Williamson wrote: > >> On Fri, 15 Aug 2025 16:59:37 +0000 > >> Mostafa Saleh <smostafa@google.com> wrote: > >> > >>> Hi Alex, > >>> > >>> On Wed, Aug 06, 2025 at 11:03:12AM -0600, Alex Williamson wrote: > >>>> vfio-platform hasn't had a meaningful contribution in years. In-tree > >>>> hardware support is predominantly only for devices which are long since > >>>> e-waste. QEMU support for platform devices is slated for removal in > >>>> QEMU-10.2. Eric Auger presented on the future of the vfio-platform > >>>> driver and difficulties supporting new devices at KVM Forum 2024, > >>>> gaining some support for removal, some disagreement, but garnering no > >>>> new hardware support, leaving the driver in a state where it cannot > >>>> be tested. > >>>> > >>>> Mark as obsolete and subject to removal. > >>> Recently(this year) in Android, we enabled VFIO-platform for protected KVM, > >>> and it’s supported in our VMM (CrosVM) [1]. > >>> CrosVM support is different from Qemu, as it doesn't require any device > >>> specific logic in the VMM, however, it relies on loading a device tree > >>> template in runtime (with “compatiable” string...) and it will just > >>> override regs, irqs.. So it doesn’t need device knowledge (at least for now) > >>> Similarly, the kernel doesn’t need reset drivers as the hypervisor handles that. > >> I think what we attempt to achieve in vfio is repeatability and data > >> integrity independent of the hypervisor. IOW, if we 'kill -9' the > >> hypervisor process, the kernel can bring the device back to a default > >> state where the device isn't wedged or leaking information through the > >> device to the next use case. If the hypervisor wants to support > >> enhanced resets on top of that, that's great, but I think it becomes > >> difficult to argue that vfio-platform itself holds up its end of the > >> bargain if we're really trusting the hypervisor to handle these aspects. > > Sorry I was not clear, we only use that in Android for ARM64 and pKVM, > > where the hypervisor in this context means the code running in EL2 which > > is more privileged than the kernel, so it should be trusted. > > However, as I mentioned that code is not upstream yet, so it's a valid > > concern that the kernel still needs a reset driver. > > > >>> Unfortunately, there is no upstream support at the moment, we are making > >>> some -slow- progress on that [2][3] > >>> > >>> If it helps, I have access to HW that can run that and I can review/test > >>> changes, until upstream support lands; if you are open to keeping VFIO-platform. > >>> Or I can look into adding support for existing upstream HW(with platforms I am > >>> familiar with as Pixel-6) > >> Ultimately I'll lean on Eric to make the call. I know he's concerned > >> about testing, but he raised that and various other concerns whether > >> platform device really have a future with vfio nearly a year ago and > >> nothing has changed. Currently it requires a module option opt-in to > >> enable devices that the kernel doesn't know how to reset. Is that > >> sufficient or should use of such a device taint the kernel? If any > >> device beyond the few e-waste devices that we know how to reset taint > >> the kernel, should this support really even be in the kernel? Thanks, > > I think with the way it’s supported at the moment we need the kernel > > to ensure that reset happens. > > Effectively my main concern is I cannot test vfio-platform anymore. We > had some CVEs also impacting the vfio platform code base and it is a > major issue not being able to test. That's why I was obliged, last year, > to resume the integration of a new device (the tegra234 mgbe), nobody > seemed to be really interested in and this work could not be upstreamed > due to lack of traction and its hacky nature. > > You did not really comment on which kind of devices were currently > integrated. Are they within the original scope of vfio (with DMA > capabilities and protected by an IOMMU)? Last discussion we had in > https://lore.kernel.org/all/ZvvLpLUZnj-Z_tEs@google.com/ led to the > conclusion that maybe VFIO was not the best suited framework. At the moment, Android device assignement only supports DMA capable devices which are behind an IOMMU, and we use VFIO-platform for that, most of our use cases are accelerators. In that thread, I was looking into adding support for simpler devices (such as sensors) but as discussed that won’t be done through VFIO-platform. Ignoring Android, as I mentioned, I can work on adding support for existing upstream platforms (preferably ARM64, that I can get access to) such as Pixel-6, which should make it easier to test. Also, we have some interest on adding new features such as run-time power management. > > In case we keep the driver in, I think we need to get a garantee that > you or someone else at Google commits to review and test potential > changes with a perspective to take over its maintenance. I can’t make guarantees on behalf of Google, but I can contribute in reviewing/testing/maintenance of the driver as far as I am able to. If you want, you can add me as reviewer to the driver. Thanks, Mostafa > > Thanks > > Eric > > > > > But maybe instead of having that specific reset handler for VFIO, we > > can rely on the “shutdown” method already existing in "platform_driver"? > > I believe that should put the device in a state where it can be re-probed > > safely. Although not all devices implement that but it seems more generic > > and scalable. > > > > Thanks, > > Mostafa > > > >> Alex > >> > ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [PATCH 2/2] vfio/platform: Mark for removal 2025-08-20 15:20 ` Mostafa Saleh @ 2025-08-20 16:29 ` Eric Auger 2025-08-20 20:25 ` Mostafa Saleh 0 siblings, 1 reply; 18+ messages in thread From: Eric Auger @ 2025-08-20 16:29 UTC (permalink / raw) To: Mostafa Saleh; +Cc: Alex Williamson, kvm, linux-kernel, clg Hi Mostafa, On 8/20/25 5:20 PM, Mostafa Saleh wrote: > Hi Eric, > > On Tue, Aug 19, 2025 at 11:58:32AM +0200, Eric Auger wrote: >> Hi Mostafa, >> >> On 8/18/25 7:33 PM, Mostafa Saleh wrote: >>> On Mon, Aug 18, 2025 at 10:52:42AM -0600, Alex Williamson wrote: >>>> On Fri, 15 Aug 2025 16:59:37 +0000 >>>> Mostafa Saleh <smostafa@google.com> wrote: >>>> >>>>> Hi Alex, >>>>> >>>>> On Wed, Aug 06, 2025 at 11:03:12AM -0600, Alex Williamson wrote: >>>>>> vfio-platform hasn't had a meaningful contribution in years. In-tree >>>>>> hardware support is predominantly only for devices which are long since >>>>>> e-waste. QEMU support for platform devices is slated for removal in >>>>>> QEMU-10.2. Eric Auger presented on the future of the vfio-platform >>>>>> driver and difficulties supporting new devices at KVM Forum 2024, >>>>>> gaining some support for removal, some disagreement, but garnering no >>>>>> new hardware support, leaving the driver in a state where it cannot >>>>>> be tested. >>>>>> >>>>>> Mark as obsolete and subject to removal. >>>>> Recently(this year) in Android, we enabled VFIO-platform for protected KVM, >>>>> and it’s supported in our VMM (CrosVM) [1]. >>>>> CrosVM support is different from Qemu, as it doesn't require any device >>>>> specific logic in the VMM, however, it relies on loading a device tree >>>>> template in runtime (with “compatiable” string...) and it will just >>>>> override regs, irqs.. So it doesn’t need device knowledge (at least for now) >>>>> Similarly, the kernel doesn’t need reset drivers as the hypervisor handles that. >>>> I think what we attempt to achieve in vfio is repeatability and data >>>> integrity independent of the hypervisor. IOW, if we 'kill -9' the >>>> hypervisor process, the kernel can bring the device back to a default >>>> state where the device isn't wedged or leaking information through the >>>> device to the next use case. If the hypervisor wants to support >>>> enhanced resets on top of that, that's great, but I think it becomes >>>> difficult to argue that vfio-platform itself holds up its end of the >>>> bargain if we're really trusting the hypervisor to handle these aspects. >>> Sorry I was not clear, we only use that in Android for ARM64 and pKVM, >>> where the hypervisor in this context means the code running in EL2 which >>> is more privileged than the kernel, so it should be trusted. >>> However, as I mentioned that code is not upstream yet, so it's a valid >>> concern that the kernel still needs a reset driver. >>> >>>>> Unfortunately, there is no upstream support at the moment, we are making >>>>> some -slow- progress on that [2][3] >>>>> >>>>> If it helps, I have access to HW that can run that and I can review/test >>>>> changes, until upstream support lands; if you are open to keeping VFIO-platform. >>>>> Or I can look into adding support for existing upstream HW(with platforms I am >>>>> familiar with as Pixel-6) >>>> Ultimately I'll lean on Eric to make the call. I know he's concerned >>>> about testing, but he raised that and various other concerns whether >>>> platform device really have a future with vfio nearly a year ago and >>>> nothing has changed. Currently it requires a module option opt-in to >>>> enable devices that the kernel doesn't know how to reset. Is that >>>> sufficient or should use of such a device taint the kernel? If any >>>> device beyond the few e-waste devices that we know how to reset taint >>>> the kernel, should this support really even be in the kernel? Thanks, >>> I think with the way it’s supported at the moment we need the kernel >>> to ensure that reset happens. >> Effectively my main concern is I cannot test vfio-platform anymore. We >> had some CVEs also impacting the vfio platform code base and it is a >> major issue not being able to test. That's why I was obliged, last year, >> to resume the integration of a new device (the tegra234 mgbe), nobody >> seemed to be really interested in and this work could not be upstreamed >> due to lack of traction and its hacky nature. >> >> You did not really comment on which kind of devices were currently >> integrated. Are they within the original scope of vfio (with DMA >> capabilities and protected by an IOMMU)? Last discussion we had in >> https://lore.kernel.org/all/ZvvLpLUZnj-Z_tEs@google.com/ led to the >> conclusion that maybe VFIO was not the best suited framework. > At the moment, Android device assignement only supports DMA capable > devices which are behind an IOMMU, and we use VFIO-platform for that, > most of our use cases are accelerators. > > In that thread, I was looking into adding support for simpler devices > (such as sensors) but as discussed that won’t be done through > VFIO-platform. > > Ignoring Android, as I mentioned, I can work on adding support for > existing upstream platforms (preferably ARM64, that I can get access to) > such as Pixel-6, which should make it easier to test. > > Also, we have some interest on adding new features such as run-time > power management. OK fair enough. If Alex agrees then we can wait for those efforts. Also I think it would make sense to formalize the way you reset the devices (I understand the hyp does that under the hood). > >> In case we keep the driver in, I think we need to get a garantee that >> you or someone else at Google commits to review and test potential >> changes with a perspective to take over its maintenance. > I can’t make guarantees on behalf of Google, but I can contribute in > reviewing/testing/maintenance of the driver as far as I am able to. > If you want, you can add me as reviewer to the driver. I understand. I think the usual way then is for you to send a patch to update the Maintainers file. Thanks Eric > > Thanks, > Mostafa > > >> Thanks >> >> Eric >> >>> But maybe instead of having that specific reset handler for VFIO, we >>> can rely on the “shutdown” method already existing in "platform_driver"? >>> I believe that should put the device in a state where it can be re-probed >>> safely. Although not all devices implement that but it seems more generic >>> and scalable. >>> >>> Thanks, >>> Mostafa >>> >>>> Alex >>>> ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [PATCH 2/2] vfio/platform: Mark for removal 2025-08-20 16:29 ` Eric Auger @ 2025-08-20 20:25 ` Mostafa Saleh 2025-08-25 13:48 ` Pranjal Shrivastava 0 siblings, 1 reply; 18+ messages in thread From: Mostafa Saleh @ 2025-08-20 20:25 UTC (permalink / raw) To: Eric Auger; +Cc: Alex Williamson, kvm, linux-kernel, clg Hi Eric, On Wed, Aug 20, 2025 at 06:29:27PM +0200, Eric Auger wrote: > Hi Mostafa, > > On 8/20/25 5:20 PM, Mostafa Saleh wrote: > > Hi Eric, > > > > On Tue, Aug 19, 2025 at 11:58:32AM +0200, Eric Auger wrote: > >> Hi Mostafa, > >> > >> On 8/18/25 7:33 PM, Mostafa Saleh wrote: > >>> On Mon, Aug 18, 2025 at 10:52:42AM -0600, Alex Williamson wrote: > >>>> On Fri, 15 Aug 2025 16:59:37 +0000 > >>>> Mostafa Saleh <smostafa@google.com> wrote: > >>>> > >>>>> Hi Alex, > >>>>> > >>>>> On Wed, Aug 06, 2025 at 11:03:12AM -0600, Alex Williamson wrote: > >>>>>> vfio-platform hasn't had a meaningful contribution in years. In-tree > >>>>>> hardware support is predominantly only for devices which are long since > >>>>>> e-waste. QEMU support for platform devices is slated for removal in > >>>>>> QEMU-10.2. Eric Auger presented on the future of the vfio-platform > >>>>>> driver and difficulties supporting new devices at KVM Forum 2024, > >>>>>> gaining some support for removal, some disagreement, but garnering no > >>>>>> new hardware support, leaving the driver in a state where it cannot > >>>>>> be tested. > >>>>>> > >>>>>> Mark as obsolete and subject to removal. > >>>>> Recently(this year) in Android, we enabled VFIO-platform for protected KVM, > >>>>> and it’s supported in our VMM (CrosVM) [1]. > >>>>> CrosVM support is different from Qemu, as it doesn't require any device > >>>>> specific logic in the VMM, however, it relies on loading a device tree > >>>>> template in runtime (with “compatiable” string...) and it will just > >>>>> override regs, irqs.. So it doesn’t need device knowledge (at least for now) > >>>>> Similarly, the kernel doesn’t need reset drivers as the hypervisor handles that. > >>>> I think what we attempt to achieve in vfio is repeatability and data > >>>> integrity independent of the hypervisor. IOW, if we 'kill -9' the > >>>> hypervisor process, the kernel can bring the device back to a default > >>>> state where the device isn't wedged or leaking information through the > >>>> device to the next use case. If the hypervisor wants to support > >>>> enhanced resets on top of that, that's great, but I think it becomes > >>>> difficult to argue that vfio-platform itself holds up its end of the > >>>> bargain if we're really trusting the hypervisor to handle these aspects. > >>> Sorry I was not clear, we only use that in Android for ARM64 and pKVM, > >>> where the hypervisor in this context means the code running in EL2 which > >>> is more privileged than the kernel, so it should be trusted. > >>> However, as I mentioned that code is not upstream yet, so it's a valid > >>> concern that the kernel still needs a reset driver. > >>> > >>>>> Unfortunately, there is no upstream support at the moment, we are making > >>>>> some -slow- progress on that [2][3] > >>>>> > >>>>> If it helps, I have access to HW that can run that and I can review/test > >>>>> changes, until upstream support lands; if you are open to keeping VFIO-platform. > >>>>> Or I can look into adding support for existing upstream HW(with platforms I am > >>>>> familiar with as Pixel-6) > >>>> Ultimately I'll lean on Eric to make the call. I know he's concerned > >>>> about testing, but he raised that and various other concerns whether > >>>> platform device really have a future with vfio nearly a year ago and > >>>> nothing has changed. Currently it requires a module option opt-in to > >>>> enable devices that the kernel doesn't know how to reset. Is that > >>>> sufficient or should use of such a device taint the kernel? If any > >>>> device beyond the few e-waste devices that we know how to reset taint > >>>> the kernel, should this support really even be in the kernel? Thanks, > >>> I think with the way it’s supported at the moment we need the kernel > >>> to ensure that reset happens. > >> Effectively my main concern is I cannot test vfio-platform anymore. We > >> had some CVEs also impacting the vfio platform code base and it is a > >> major issue not being able to test. That's why I was obliged, last year, > >> to resume the integration of a new device (the tegra234 mgbe), nobody > >> seemed to be really interested in and this work could not be upstreamed > >> due to lack of traction and its hacky nature. > >> > >> You did not really comment on which kind of devices were currently > >> integrated. Are they within the original scope of vfio (with DMA > >> capabilities and protected by an IOMMU)? Last discussion we had in > >> https://lore.kernel.org/all/ZvvLpLUZnj-Z_tEs@google.com/ led to the > >> conclusion that maybe VFIO was not the best suited framework. > > At the moment, Android device assignement only supports DMA capable > > devices which are behind an IOMMU, and we use VFIO-platform for that, > > most of our use cases are accelerators. > > > > In that thread, I was looking into adding support for simpler devices > > (such as sensors) but as discussed that won’t be done through > > VFIO-platform. > > > > Ignoring Android, as I mentioned, I can work on adding support for > > existing upstream platforms (preferably ARM64, that I can get access to) > > such as Pixel-6, which should make it easier to test. > > > > Also, we have some interest on adding new features such as run-time > > power management. > > OK fair enough. If Alex agrees then we can wait for those efforts. Also > I think it would make sense to formalize the way you reset the devices > (I understand the hyp does that under the hood). I think currently - with some help from the platform bus- we can rely on the existing shutdown method, instead of specific hooks. As the hypervisor logic will only be for ARM64 (at least for now), I can look more into this. But I think the top priority would be to establish a decent platform to test with, I will start looking into Pixel-6 (although that would need to land IOMMU support for it upstream first). I also have a morello board with SMMUv3, but I think it's all PCI. > > > >> In case we keep the driver in, I think we need to get a garantee that > >> you or someone else at Google commits to review and test potential > >> changes with a perspective to take over its maintenance. > > I can’t make guarantees on behalf of Google, but I can contribute in > > reviewing/testing/maintenance of the driver as far as I am able to. > > If you want, you can add me as reviewer to the driver. > > I understand. I think the usual way then is for you to send a patch to > update the Maintainers file. I see, I will send one shortly. Thanks, Mostafa > > Thanks > > Eric > > > > Thanks, > > Mostafa > > > > > >> Thanks > >> > >> Eric > >> > >>> But maybe instead of having that specific reset handler for VFIO, we > >>> can rely on the “shutdown” method already existing in "platform_driver"? > >>> I believe that should put the device in a state where it can be re-probed > >>> safely. Although not all devices implement that but it seems more generic > >>> and scalable. > >>> > >>> Thanks, > >>> Mostafa > >>> > >>>> Alex > >>>> > ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [PATCH 2/2] vfio/platform: Mark for removal 2025-08-20 20:25 ` Mostafa Saleh @ 2025-08-25 13:48 ` Pranjal Shrivastava 2025-08-25 16:15 ` Alex Williamson 0 siblings, 1 reply; 18+ messages in thread From: Pranjal Shrivastava @ 2025-08-25 13:48 UTC (permalink / raw) To: Mostafa Saleh; +Cc: Eric Auger, Alex Williamson, kvm, linux-kernel, clg On Wed, Aug 20, 2025 at 08:25:47PM +0000, Mostafa Saleh wrote: > Hi Eric, > > On Wed, Aug 20, 2025 at 06:29:27PM +0200, Eric Auger wrote: > > Hi Mostafa, > > > > On 8/20/25 5:20 PM, Mostafa Saleh wrote: > > > Hi Eric, > > > > > > On Tue, Aug 19, 2025 at 11:58:32AM +0200, Eric Auger wrote: > > >> Hi Mostafa, > > >> > > >> On 8/18/25 7:33 PM, Mostafa Saleh wrote: > > >>> On Mon, Aug 18, 2025 at 10:52:42AM -0600, Alex Williamson wrote: > > >>>> On Fri, 15 Aug 2025 16:59:37 +0000 > > >>>> Mostafa Saleh <smostafa@google.com> wrote: > > >>>> > > >>>>> Hi Alex, > > >>>>> > > >>>>> On Wed, Aug 06, 2025 at 11:03:12AM -0600, Alex Williamson wrote: > > >>>>>> vfio-platform hasn't had a meaningful contribution in years. In-tree > > >>>>>> hardware support is predominantly only for devices which are long since > > >>>>>> e-waste. QEMU support for platform devices is slated for removal in > > >>>>>> QEMU-10.2. Eric Auger presented on the future of the vfio-platform > > >>>>>> driver and difficulties supporting new devices at KVM Forum 2024, > > >>>>>> gaining some support for removal, some disagreement, but garnering no > > >>>>>> new hardware support, leaving the driver in a state where it cannot > > >>>>>> be tested. > > >>>>>> > > >>>>>> Mark as obsolete and subject to removal. > > >>>>> Recently(this year) in Android, we enabled VFIO-platform for protected KVM, > > >>>>> and it’s supported in our VMM (CrosVM) [1]. > > >>>>> CrosVM support is different from Qemu, as it doesn't require any device > > >>>>> specific logic in the VMM, however, it relies on loading a device tree > > >>>>> template in runtime (with “compatiable” string...) and it will just > > >>>>> override regs, irqs.. So it doesn’t need device knowledge (at least for now) > > >>>>> Similarly, the kernel doesn’t need reset drivers as the hypervisor handles that. > > >>>> I think what we attempt to achieve in vfio is repeatability and data > > >>>> integrity independent of the hypervisor. IOW, if we 'kill -9' the > > >>>> hypervisor process, the kernel can bring the device back to a default > > >>>> state where the device isn't wedged or leaking information through the > > >>>> device to the next use case. If the hypervisor wants to support > > >>>> enhanced resets on top of that, that's great, but I think it becomes > > >>>> difficult to argue that vfio-platform itself holds up its end of the > > >>>> bargain if we're really trusting the hypervisor to handle these aspects. > > >>> Sorry I was not clear, we only use that in Android for ARM64 and pKVM, > > >>> where the hypervisor in this context means the code running in EL2 which > > >>> is more privileged than the kernel, so it should be trusted. > > >>> However, as I mentioned that code is not upstream yet, so it's a valid > > >>> concern that the kernel still needs a reset driver. > > >>> > > >>>>> Unfortunately, there is no upstream support at the moment, we are making > > >>>>> some -slow- progress on that [2][3] > > >>>>> > > >>>>> If it helps, I have access to HW that can run that and I can review/test > > >>>>> changes, until upstream support lands; if you are open to keeping VFIO-platform. > > >>>>> Or I can look into adding support for existing upstream HW(with platforms I am > > >>>>> familiar with as Pixel-6) > > >>>> Ultimately I'll lean on Eric to make the call. I know he's concerned > > >>>> about testing, but he raised that and various other concerns whether > > >>>> platform device really have a future with vfio nearly a year ago and > > >>>> nothing has changed. Currently it requires a module option opt-in to > > >>>> enable devices that the kernel doesn't know how to reset. Is that > > >>>> sufficient or should use of such a device taint the kernel? If any > > >>>> device beyond the few e-waste devices that we know how to reset taint > > >>>> the kernel, should this support really even be in the kernel? Thanks, > > >>> I think with the way it’s supported at the moment we need the kernel > > >>> to ensure that reset happens. > > >> Effectively my main concern is I cannot test vfio-platform anymore. We > > >> had some CVEs also impacting the vfio platform code base and it is a > > >> major issue not being able to test. That's why I was obliged, last year, > > >> to resume the integration of a new device (the tegra234 mgbe), nobody > > >> seemed to be really interested in and this work could not be upstreamed > > >> due to lack of traction and its hacky nature. > > >> > > >> You did not really comment on which kind of devices were currently > > >> integrated. Are they within the original scope of vfio (with DMA > > >> capabilities and protected by an IOMMU)? Last discussion we had in > > >> https://lore.kernel.org/all/ZvvLpLUZnj-Z_tEs@google.com/ led to the > > >> conclusion that maybe VFIO was not the best suited framework. > > > At the moment, Android device assignement only supports DMA capable > > > devices which are behind an IOMMU, and we use VFIO-platform for that, > > > most of our use cases are accelerators. > > > > > > In that thread, I was looking into adding support for simpler devices > > > (such as sensors) but as discussed that won’t be done through > > > VFIO-platform. > > > > > > Ignoring Android, as I mentioned, I can work on adding support for > > > existing upstream platforms (preferably ARM64, that I can get access to) > > > such as Pixel-6, which should make it easier to test. > > > > > > Also, we have some interest on adding new features such as run-time > > > power management. > > > > OK fair enough. If Alex agrees then we can wait for those efforts. Also > > I think it would make sense to formalize the way you reset the devices > > (I understand the hyp does that under the hood). > > I think currently - with some help from the platform bus- we can rely on > the existing shutdown method, instead of specific hooks. > As the hypervisor logic will only be for ARM64 (at least for now), I can > look more into this. > > But I think the top priority would be to establish a decent platform to > test with, I will start looking into Pixel-6 (although that would need > to land IOMMU support for it upstream first). I also have a morello > board with SMMUv3, but I think it's all PCI. > > > > > > >> In case we keep the driver in, I think we need to get a garantee that > > >> you or someone else at Google commits to review and test potential > > >> changes with a perspective to take over its maintenance. > > > I can’t make guarantees on behalf of Google, but I can contribute in > > > reviewing/testing/maintenance of the driver as far as I am able to. > > > If you want, you can add me as reviewer to the driver. > > > > I understand. I think the usual way then is for you to send a patch to > > update the Maintainers file. > > I see, I will send one shortly. > I could contribute time to help with the maintenance effort here, if needed. Please let me know if you'd like that. > Thanks, > Mostafa > Thanks, Praan > > > > Thanks > > > > Eric > > > > > > Thanks, > > > Mostafa > > > > > > > > >> Thanks > > >> > > >> Eric > > >> > > >>> But maybe instead of having that specific reset handler for VFIO, we > > >>> can rely on the “shutdown” method already existing in "platform_driver"? > > >>> I believe that should put the device in a state where it can be re-probed > > >>> safely. Although not all devices implement that but it seems more generic > > >>> and scalable. > > >>> > > >>> Thanks, > > >>> Mostafa > > >>> > > >>>> Alex > > >>>> > > > ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [PATCH 2/2] vfio/platform: Mark for removal 2025-08-25 13:48 ` Pranjal Shrivastava @ 2025-08-25 16:15 ` Alex Williamson 2025-08-25 16:48 ` Eric Auger 0 siblings, 1 reply; 18+ messages in thread From: Alex Williamson @ 2025-08-25 16:15 UTC (permalink / raw) To: Pranjal Shrivastava; +Cc: Mostafa Saleh, Eric Auger, kvm, linux-kernel, clg On Mon, 25 Aug 2025 13:48:59 +0000 Pranjal Shrivastava <praan@google.com> wrote: > On Wed, Aug 20, 2025 at 08:25:47PM +0000, Mostafa Saleh wrote: > > Hi Eric, > > > > On Wed, Aug 20, 2025 at 06:29:27PM +0200, Eric Auger wrote: > > > Hi Mostafa, > > > > > > On 8/20/25 5:20 PM, Mostafa Saleh wrote: > > > > Hi Eric, > > > > > > > > On Tue, Aug 19, 2025 at 11:58:32AM +0200, Eric Auger wrote: > > > >> Hi Mostafa, > > > >> > > > >> On 8/18/25 7:33 PM, Mostafa Saleh wrote: > > > >>> On Mon, Aug 18, 2025 at 10:52:42AM -0600, Alex Williamson wrote: > > > >>>> On Fri, 15 Aug 2025 16:59:37 +0000 > > > >>>> Mostafa Saleh <smostafa@google.com> wrote: > > > >>>> > > > >>>>> Hi Alex, > > > >>>>> > > > >>>>> On Wed, Aug 06, 2025 at 11:03:12AM -0600, Alex Williamson wrote: > > > >>>>>> vfio-platform hasn't had a meaningful contribution in years. In-tree > > > >>>>>> hardware support is predominantly only for devices which are long since > > > >>>>>> e-waste. QEMU support for platform devices is slated for removal in > > > >>>>>> QEMU-10.2. Eric Auger presented on the future of the vfio-platform > > > >>>>>> driver and difficulties supporting new devices at KVM Forum 2024, > > > >>>>>> gaining some support for removal, some disagreement, but garnering no > > > >>>>>> new hardware support, leaving the driver in a state where it cannot > > > >>>>>> be tested. > > > >>>>>> > > > >>>>>> Mark as obsolete and subject to removal. > > > >>>>> Recently(this year) in Android, we enabled VFIO-platform for protected KVM, > > > >>>>> and it’s supported in our VMM (CrosVM) [1]. > > > >>>>> CrosVM support is different from Qemu, as it doesn't require any device > > > >>>>> specific logic in the VMM, however, it relies on loading a device tree > > > >>>>> template in runtime (with “compatiable” string...) and it will just > > > >>>>> override regs, irqs.. So it doesn’t need device knowledge (at least for now) > > > >>>>> Similarly, the kernel doesn’t need reset drivers as the hypervisor handles that. > > > >>>> I think what we attempt to achieve in vfio is repeatability and data > > > >>>> integrity independent of the hypervisor. IOW, if we 'kill -9' the > > > >>>> hypervisor process, the kernel can bring the device back to a default > > > >>>> state where the device isn't wedged or leaking information through the > > > >>>> device to the next use case. If the hypervisor wants to support > > > >>>> enhanced resets on top of that, that's great, but I think it becomes > > > >>>> difficult to argue that vfio-platform itself holds up its end of the > > > >>>> bargain if we're really trusting the hypervisor to handle these aspects. > > > >>> Sorry I was not clear, we only use that in Android for ARM64 and pKVM, > > > >>> where the hypervisor in this context means the code running in EL2 which > > > >>> is more privileged than the kernel, so it should be trusted. > > > >>> However, as I mentioned that code is not upstream yet, so it's a valid > > > >>> concern that the kernel still needs a reset driver. > > > >>> > > > >>>>> Unfortunately, there is no upstream support at the moment, we are making > > > >>>>> some -slow- progress on that [2][3] > > > >>>>> > > > >>>>> If it helps, I have access to HW that can run that and I can review/test > > > >>>>> changes, until upstream support lands; if you are open to keeping VFIO-platform. > > > >>>>> Or I can look into adding support for existing upstream HW(with platforms I am > > > >>>>> familiar with as Pixel-6) > > > >>>> Ultimately I'll lean on Eric to make the call. I know he's concerned > > > >>>> about testing, but he raised that and various other concerns whether > > > >>>> platform device really have a future with vfio nearly a year ago and > > > >>>> nothing has changed. Currently it requires a module option opt-in to > > > >>>> enable devices that the kernel doesn't know how to reset. Is that > > > >>>> sufficient or should use of such a device taint the kernel? If any > > > >>>> device beyond the few e-waste devices that we know how to reset taint > > > >>>> the kernel, should this support really even be in the kernel? Thanks, > > > >>> I think with the way it’s supported at the moment we need the kernel > > > >>> to ensure that reset happens. > > > >> Effectively my main concern is I cannot test vfio-platform anymore. We > > > >> had some CVEs also impacting the vfio platform code base and it is a > > > >> major issue not being able to test. That's why I was obliged, last year, > > > >> to resume the integration of a new device (the tegra234 mgbe), nobody > > > >> seemed to be really interested in and this work could not be upstreamed > > > >> due to lack of traction and its hacky nature. > > > >> > > > >> You did not really comment on which kind of devices were currently > > > >> integrated. Are they within the original scope of vfio (with DMA > > > >> capabilities and protected by an IOMMU)? Last discussion we had in > > > >> https://lore.kernel.org/all/ZvvLpLUZnj-Z_tEs@google.com/ led to the > > > >> conclusion that maybe VFIO was not the best suited framework. > > > > At the moment, Android device assignement only supports DMA capable > > > > devices which are behind an IOMMU, and we use VFIO-platform for that, > > > > most of our use cases are accelerators. > > > > > > > > In that thread, I was looking into adding support for simpler devices > > > > (such as sensors) but as discussed that won’t be done through > > > > VFIO-platform. > > > > > > > > Ignoring Android, as I mentioned, I can work on adding support for > > > > existing upstream platforms (preferably ARM64, that I can get access to) > > > > such as Pixel-6, which should make it easier to test. > > > > > > > > Also, we have some interest on adding new features such as run-time > > > > power management. > > > > > > OK fair enough. If Alex agrees then we can wait for those efforts. Also > > > I think it would make sense to formalize the way you reset the devices > > > (I understand the hyp does that under the hood). > > > > I think currently - with some help from the platform bus- we can rely on > > the existing shutdown method, instead of specific hooks. > > As the hypervisor logic will only be for ARM64 (at least for now), I can > > look more into this. > > > > But I think the top priority would be to establish a decent platform to > > test with, I will start looking into Pixel-6 (although that would need > > to land IOMMU support for it upstream first). I also have a morello > > board with SMMUv3, but I think it's all PCI. > > > > > > > > > >> In case we keep the driver in, I think we need to get a garantee that > > > >> you or someone else at Google commits to review and test potential > > > >> changes with a perspective to take over its maintenance. > > > > I can’t make guarantees on behalf of Google, but I can contribute in > > > > reviewing/testing/maintenance of the driver as far as I am able to. > > > > If you want, you can add me as reviewer to the driver. > > > > > > I understand. I think the usual way then is for you to send a patch to > > > update the Maintainers file. > > > > I see, I will send one shortly. > > > > I could contribute time to help with the maintenance effort here, if > needed. Please let me know if you'd like that. You can join Mostafa and post a patch to be added as a designated reviewer. If we're not going to deprecate vfio-platform overall for now, what about vfio-amba and all the reset drivers? It seems that even if Google cares about vfio-platform, these still fall outside of what's being used or tested. Should we drive something like below to see what comes out of the woodwork?: diff --git a/drivers/vfio/platform/Kconfig b/drivers/vfio/platform/Kconfig index 88fcde51f024..c6be29b2c24b 100644 --- a/drivers/vfio/platform/Kconfig +++ b/drivers/vfio/platform/Kconfig @@ -17,10 +17,13 @@ config VFIO_PLATFORM If you don't know what to do here, say N. config VFIO_AMBA - tristate "VFIO support for AMBA devices" + tristate "VFIO support for AMBA devices (DEPRECATED)" depends on ARM_AMBA || COMPILE_TEST select VFIO_PLATFORM_BASE help + The vfio-amba driver is deprecated and will be removed in a + future kernel release. + Support for ARM AMBA devices with VFIO. This is required to make use of ARM AMBA devices present on the system using the VFIO framework. diff --git a/drivers/vfio/platform/reset/Kconfig b/drivers/vfio/platform/reset/Kconfig index dcc08dc145a5..70af0dbe293b 100644 --- a/drivers/vfio/platform/reset/Kconfig +++ b/drivers/vfio/platform/reset/Kconfig @@ -1,21 +1,21 @@ # SPDX-License-Identifier: GPL-2.0-only if VFIO_PLATFORM config VFIO_PLATFORM_CALXEDAXGMAC_RESET - tristate "VFIO support for calxeda xgmac reset" + tristate "VFIO support for calxeda xgmac reset (DEPRECATED)" help Enables the VFIO platform driver to handle reset for Calxeda xgmac If you don't know what to do here, say N. config VFIO_PLATFORM_AMDXGBE_RESET - tristate "VFIO support for AMD XGBE reset" + tristate "VFIO support for AMD XGBE reset (DEPRECATED)" help Enables the VFIO platform driver to handle reset for AMD XGBE If you don't know what to do here, say N. config VFIO_PLATFORM_BCMFLEXRM_RESET - tristate "VFIO support for Broadcom FlexRM reset" + tristate "VFIO support for Broadcom FlexRM reset (DEPRECATED)" depends on ARCH_BCM_IPROC || COMPILE_TEST default ARCH_BCM_IPROC help diff --git a/drivers/vfio/platform/reset/vfio_platform_amdxgbe.c b/drivers/vfio/platform/reset/vfio_platform_amdxgbe.c index abdca900802d..45f386a042a9 100644 --- a/drivers/vfio/platform/reset/vfio_platform_amdxgbe.c +++ b/drivers/vfio/platform/reset/vfio_platform_amdxgbe.c @@ -52,6 +52,8 @@ static int vfio_platform_amdxgbe_reset(struct vfio_platform_device *vdev) u32 dma_mr_value, pcs_value, value; unsigned int count; + dev_err_once(vdev->device, "DEPRECATION: VFIO AMD XGBE platform reset is deprecated and will be removed in a future kernel release\n"); + if (!xgmac_regs->ioaddr) { xgmac_regs->ioaddr = ioremap(xgmac_regs->addr, xgmac_regs->size); diff --git a/drivers/vfio/platform/reset/vfio_platform_bcmflexrm.c b/drivers/vfio/platform/reset/vfio_platform_bcmflexrm.c index 1131ebe4837d..51c9d156f307 100644 --- a/drivers/vfio/platform/reset/vfio_platform_bcmflexrm.c +++ b/drivers/vfio/platform/reset/vfio_platform_bcmflexrm.c @@ -72,6 +72,8 @@ static int vfio_platform_bcmflexrm_reset(struct vfio_platform_device *vdev) int rc = 0, ret = 0, ring_num = 0; struct vfio_platform_region *reg = &vdev->regions[0]; + dev_err_once(vdev->device, "DEPRECATION: VFIO Broadcom FlexRM platform reset is deprecated and will be removed in a future kernel release\n"); + /* Map FlexRM ring registers if not mapped */ if (!reg->ioaddr) { reg->ioaddr = ioremap(reg->addr, reg->size); diff --git a/drivers/vfio/platform/reset/vfio_platform_calxedaxgmac.c b/drivers/vfio/platform/reset/vfio_platform_calxedaxgmac.c index 63cc7f0b2e4a..a298045a8e19 100644 --- a/drivers/vfio/platform/reset/vfio_platform_calxedaxgmac.c +++ b/drivers/vfio/platform/reset/vfio_platform_calxedaxgmac.c @@ -50,6 +50,8 @@ static int vfio_platform_calxedaxgmac_reset(struct vfio_platform_device *vdev) { struct vfio_platform_region *reg = &vdev->regions[0]; + dev_err_once(vdev->device, "DEPRECATION: VFIO Calxeda xgmac platform reset is deprecated and will be removed in a future kernel release\n"); + if (!reg->ioaddr) { reg->ioaddr = ioremap(reg->addr, reg->size); diff --git a/drivers/vfio/platform/vfio_amba.c b/drivers/vfio/platform/vfio_amba.c index ff8ff8480968..9f5c527baa8a 100644 --- a/drivers/vfio/platform/vfio_amba.c +++ b/drivers/vfio/platform/vfio_amba.c @@ -70,6 +70,8 @@ static int vfio_amba_probe(struct amba_device *adev, const struct amba_id *id) struct vfio_platform_device *vdev; int ret; + dev_err_once(&adev->dev, "DEPRECATION: vfio-amba is deprecated and will be removed in a future kernel release\n"); + vdev = vfio_alloc_device(vfio_platform_device, vdev, &adev->dev, &vfio_amba_ops); if (IS_ERR(vdev)) ^ permalink raw reply related [flat|nested] 18+ messages in thread
* Re: [PATCH 2/2] vfio/platform: Mark for removal 2025-08-25 16:15 ` Alex Williamson @ 2025-08-25 16:48 ` Eric Auger 0 siblings, 0 replies; 18+ messages in thread From: Eric Auger @ 2025-08-25 16:48 UTC (permalink / raw) To: Alex Williamson, Pranjal Shrivastava Cc: Mostafa Saleh, kvm, linux-kernel, clg Hi Alex, On 8/25/25 6:15 PM, Alex Williamson wrote: > On Mon, 25 Aug 2025 13:48:59 +0000 > Pranjal Shrivastava <praan@google.com> wrote: > >> On Wed, Aug 20, 2025 at 08:25:47PM +0000, Mostafa Saleh wrote: >>> Hi Eric, >>> >>> On Wed, Aug 20, 2025 at 06:29:27PM +0200, Eric Auger wrote: >>>> Hi Mostafa, >>>> >>>> On 8/20/25 5:20 PM, Mostafa Saleh wrote: >>>>> Hi Eric, >>>>> >>>>> On Tue, Aug 19, 2025 at 11:58:32AM +0200, Eric Auger wrote: >>>>>> Hi Mostafa, >>>>>> >>>>>> On 8/18/25 7:33 PM, Mostafa Saleh wrote: >>>>>>> On Mon, Aug 18, 2025 at 10:52:42AM -0600, Alex Williamson wrote: >>>>>>>> On Fri, 15 Aug 2025 16:59:37 +0000 >>>>>>>> Mostafa Saleh <smostafa@google.com> wrote: >>>>>>>> >>>>>>>>> Hi Alex, >>>>>>>>> >>>>>>>>> On Wed, Aug 06, 2025 at 11:03:12AM -0600, Alex Williamson wrote: >>>>>>>>>> vfio-platform hasn't had a meaningful contribution in years. In-tree >>>>>>>>>> hardware support is predominantly only for devices which are long since >>>>>>>>>> e-waste. QEMU support for platform devices is slated for removal in >>>>>>>>>> QEMU-10.2. Eric Auger presented on the future of the vfio-platform >>>>>>>>>> driver and difficulties supporting new devices at KVM Forum 2024, >>>>>>>>>> gaining some support for removal, some disagreement, but garnering no >>>>>>>>>> new hardware support, leaving the driver in a state where it cannot >>>>>>>>>> be tested. >>>>>>>>>> >>>>>>>>>> Mark as obsolete and subject to removal. >>>>>>>>> Recently(this year) in Android, we enabled VFIO-platform for protected KVM, >>>>>>>>> and it’s supported in our VMM (CrosVM) [1]. >>>>>>>>> CrosVM support is different from Qemu, as it doesn't require any device >>>>>>>>> specific logic in the VMM, however, it relies on loading a device tree >>>>>>>>> template in runtime (with “compatiable” string...) and it will just >>>>>>>>> override regs, irqs.. So it doesn’t need device knowledge (at least for now) >>>>>>>>> Similarly, the kernel doesn’t need reset drivers as the hypervisor handles that. >>>>>>>> I think what we attempt to achieve in vfio is repeatability and data >>>>>>>> integrity independent of the hypervisor. IOW, if we 'kill -9' the >>>>>>>> hypervisor process, the kernel can bring the device back to a default >>>>>>>> state where the device isn't wedged or leaking information through the >>>>>>>> device to the next use case. If the hypervisor wants to support >>>>>>>> enhanced resets on top of that, that's great, but I think it becomes >>>>>>>> difficult to argue that vfio-platform itself holds up its end of the >>>>>>>> bargain if we're really trusting the hypervisor to handle these aspects. >>>>>>> Sorry I was not clear, we only use that in Android for ARM64 and pKVM, >>>>>>> where the hypervisor in this context means the code running in EL2 which >>>>>>> is more privileged than the kernel, so it should be trusted. >>>>>>> However, as I mentioned that code is not upstream yet, so it's a valid >>>>>>> concern that the kernel still needs a reset driver. >>>>>>> >>>>>>>>> Unfortunately, there is no upstream support at the moment, we are making >>>>>>>>> some -slow- progress on that [2][3] >>>>>>>>> >>>>>>>>> If it helps, I have access to HW that can run that and I can review/test >>>>>>>>> changes, until upstream support lands; if you are open to keeping VFIO-platform. >>>>>>>>> Or I can look into adding support for existing upstream HW(with platforms I am >>>>>>>>> familiar with as Pixel-6) >>>>>>>> Ultimately I'll lean on Eric to make the call. I know he's concerned >>>>>>>> about testing, but he raised that and various other concerns whether >>>>>>>> platform device really have a future with vfio nearly a year ago and >>>>>>>> nothing has changed. Currently it requires a module option opt-in to >>>>>>>> enable devices that the kernel doesn't know how to reset. Is that >>>>>>>> sufficient or should use of such a device taint the kernel? If any >>>>>>>> device beyond the few e-waste devices that we know how to reset taint >>>>>>>> the kernel, should this support really even be in the kernel? Thanks, >>>>>>> I think with the way it’s supported at the moment we need the kernel >>>>>>> to ensure that reset happens. >>>>>> Effectively my main concern is I cannot test vfio-platform anymore. We >>>>>> had some CVEs also impacting the vfio platform code base and it is a >>>>>> major issue not being able to test. That's why I was obliged, last year, >>>>>> to resume the integration of a new device (the tegra234 mgbe), nobody >>>>>> seemed to be really interested in and this work could not be upstreamed >>>>>> due to lack of traction and its hacky nature. >>>>>> >>>>>> You did not really comment on which kind of devices were currently >>>>>> integrated. Are they within the original scope of vfio (with DMA >>>>>> capabilities and protected by an IOMMU)? Last discussion we had in >>>>>> https://lore.kernel.org/all/ZvvLpLUZnj-Z_tEs@google.com/ led to the >>>>>> conclusion that maybe VFIO was not the best suited framework. >>>>> At the moment, Android device assignement only supports DMA capable >>>>> devices which are behind an IOMMU, and we use VFIO-platform for that, >>>>> most of our use cases are accelerators. >>>>> >>>>> In that thread, I was looking into adding support for simpler devices >>>>> (such as sensors) but as discussed that won’t be done through >>>>> VFIO-platform. >>>>> >>>>> Ignoring Android, as I mentioned, I can work on adding support for >>>>> existing upstream platforms (preferably ARM64, that I can get access to) >>>>> such as Pixel-6, which should make it easier to test. >>>>> >>>>> Also, we have some interest on adding new features such as run-time >>>>> power management. >>>> OK fair enough. If Alex agrees then we can wait for those efforts. Also >>>> I think it would make sense to formalize the way you reset the devices >>>> (I understand the hyp does that under the hood). >>> I think currently - with some help from the platform bus- we can rely on >>> the existing shutdown method, instead of specific hooks. >>> As the hypervisor logic will only be for ARM64 (at least for now), I can >>> look more into this. >>> >>> But I think the top priority would be to establish a decent platform to >>> test with, I will start looking into Pixel-6 (although that would need >>> to land IOMMU support for it upstream first). I also have a morello >>> board with SMMUv3, but I think it's all PCI. >>> >>>>> >>>>>> In case we keep the driver in, I think we need to get a garantee that >>>>>> you or someone else at Google commits to review and test potential >>>>>> changes with a perspective to take over its maintenance. >>>>> I can’t make guarantees on behalf of Google, but I can contribute in >>>>> reviewing/testing/maintenance of the driver as far as I am able to. >>>>> If you want, you can add me as reviewer to the driver. >>>> I understand. I think the usual way then is for you to send a patch to >>>> update the Maintainers file. >>> I see, I will send one shortly. >>> >> I could contribute time to help with the maintenance effort here, if >> needed. Please let me know if you'd like that. > You can join Mostafa and post a patch to be added as a designated > reviewer. > > If we're not going to deprecate vfio-platform overall for now, what > about vfio-amba and all the reset drivers? It seems that even if > Google cares about vfio-platform, these still fall outside of what's > being used or tested. Should we drive something like below to see what > comes out of the woodwork?: As far as I know vfio-amba has never been used. With regards to the reset driver I think this is reasonable to deprecate them as the HW has ewasted Thanks Eric > > diff --git a/drivers/vfio/platform/Kconfig b/drivers/vfio/platform/Kconfig > index 88fcde51f024..c6be29b2c24b 100644 > --- a/drivers/vfio/platform/Kconfig > +++ b/drivers/vfio/platform/Kconfig > @@ -17,10 +17,13 @@ config VFIO_PLATFORM > If you don't know what to do here, say N. > > config VFIO_AMBA > - tristate "VFIO support for AMBA devices" > + tristate "VFIO support for AMBA devices (DEPRECATED)" > depends on ARM_AMBA || COMPILE_TEST > select VFIO_PLATFORM_BASE > help > + The vfio-amba driver is deprecated and will be removed in a > + future kernel release. > + > Support for ARM AMBA devices with VFIO. This is required to make > use of ARM AMBA devices present on the system using the VFIO > framework. > diff --git a/drivers/vfio/platform/reset/Kconfig b/drivers/vfio/platform/reset/Kconfig > index dcc08dc145a5..70af0dbe293b 100644 > --- a/drivers/vfio/platform/reset/Kconfig > +++ b/drivers/vfio/platform/reset/Kconfig > @@ -1,21 +1,21 @@ > # SPDX-License-Identifier: GPL-2.0-only > if VFIO_PLATFORM > config VFIO_PLATFORM_CALXEDAXGMAC_RESET > - tristate "VFIO support for calxeda xgmac reset" > + tristate "VFIO support for calxeda xgmac reset (DEPRECATED)" > help > Enables the VFIO platform driver to handle reset for Calxeda xgmac > > If you don't know what to do here, say N. > > config VFIO_PLATFORM_AMDXGBE_RESET > - tristate "VFIO support for AMD XGBE reset" > + tristate "VFIO support for AMD XGBE reset (DEPRECATED)" > help > Enables the VFIO platform driver to handle reset for AMD XGBE > > If you don't know what to do here, say N. > > config VFIO_PLATFORM_BCMFLEXRM_RESET > - tristate "VFIO support for Broadcom FlexRM reset" > + tristate "VFIO support for Broadcom FlexRM reset (DEPRECATED)" > depends on ARCH_BCM_IPROC || COMPILE_TEST > default ARCH_BCM_IPROC > help > diff --git a/drivers/vfio/platform/reset/vfio_platform_amdxgbe.c b/drivers/vfio/platform/reset/vfio_platform_amdxgbe.c > index abdca900802d..45f386a042a9 100644 > --- a/drivers/vfio/platform/reset/vfio_platform_amdxgbe.c > +++ b/drivers/vfio/platform/reset/vfio_platform_amdxgbe.c > @@ -52,6 +52,8 @@ static int vfio_platform_amdxgbe_reset(struct vfio_platform_device *vdev) > u32 dma_mr_value, pcs_value, value; > unsigned int count; > > + dev_err_once(vdev->device, "DEPRECATION: VFIO AMD XGBE platform reset is deprecated and will be removed in a future kernel release\n"); > + > if (!xgmac_regs->ioaddr) { > xgmac_regs->ioaddr = > ioremap(xgmac_regs->addr, xgmac_regs->size); > diff --git a/drivers/vfio/platform/reset/vfio_platform_bcmflexrm.c b/drivers/vfio/platform/reset/vfio_platform_bcmflexrm.c > index 1131ebe4837d..51c9d156f307 100644 > --- a/drivers/vfio/platform/reset/vfio_platform_bcmflexrm.c > +++ b/drivers/vfio/platform/reset/vfio_platform_bcmflexrm.c > @@ -72,6 +72,8 @@ static int vfio_platform_bcmflexrm_reset(struct vfio_platform_device *vdev) > int rc = 0, ret = 0, ring_num = 0; > struct vfio_platform_region *reg = &vdev->regions[0]; > > + dev_err_once(vdev->device, "DEPRECATION: VFIO Broadcom FlexRM platform reset is deprecated and will be removed in a future kernel release\n"); > + > /* Map FlexRM ring registers if not mapped */ > if (!reg->ioaddr) { > reg->ioaddr = ioremap(reg->addr, reg->size); > diff --git a/drivers/vfio/platform/reset/vfio_platform_calxedaxgmac.c b/drivers/vfio/platform/reset/vfio_platform_calxedaxgmac.c > index 63cc7f0b2e4a..a298045a8e19 100644 > --- a/drivers/vfio/platform/reset/vfio_platform_calxedaxgmac.c > +++ b/drivers/vfio/platform/reset/vfio_platform_calxedaxgmac.c > @@ -50,6 +50,8 @@ static int vfio_platform_calxedaxgmac_reset(struct vfio_platform_device *vdev) > { > struct vfio_platform_region *reg = &vdev->regions[0]; > > + dev_err_once(vdev->device, "DEPRECATION: VFIO Calxeda xgmac platform reset is deprecated and will be removed in a future kernel release\n"); > + > if (!reg->ioaddr) { > reg->ioaddr = > ioremap(reg->addr, reg->size); > diff --git a/drivers/vfio/platform/vfio_amba.c b/drivers/vfio/platform/vfio_amba.c > index ff8ff8480968..9f5c527baa8a 100644 > --- a/drivers/vfio/platform/vfio_amba.c > +++ b/drivers/vfio/platform/vfio_amba.c > @@ -70,6 +70,8 @@ static int vfio_amba_probe(struct amba_device *adev, const struct amba_id *id) > struct vfio_platform_device *vdev; > int ret; > > + dev_err_once(&adev->dev, "DEPRECATION: vfio-amba is deprecated and will be removed in a future kernel release\n"); > + > vdev = vfio_alloc_device(vfio_platform_device, vdev, &adev->dev, > &vfio_amba_ops); > if (IS_ERR(vdev)) > ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [PATCH 0/2] vfio: Deprecate fsl-mc, platform, and amba 2025-08-06 17:03 [PATCH 0/2] vfio: Deprecate fsl-mc, platform, and amba Alex Williamson 2025-08-06 17:03 ` [PATCH 1/2] vfio/fsl-mc: Mark for removal Alex Williamson 2025-08-06 17:03 ` [PATCH 2/2] vfio/platform: " Alex Williamson @ 2025-08-07 8:12 ` Eric Auger 2025-08-11 20:23 ` Jason Gunthorpe 2025-08-15 14:47 ` Cédric Le Goater 4 siblings, 0 replies; 18+ messages in thread From: Eric Auger @ 2025-08-07 8:12 UTC (permalink / raw) To: Alex Williamson, kvm; +Cc: linux-kernel, clg Hi Alex, On 8/6/25 7:03 PM, Alex Williamson wrote: > The vfio-fsl-mc driver has been orphaned since April 2024 after the > maintainer became unresponsive. More than a year later, the driver > has only received community maintenance. Let's take the next step > towards removal by marking it obsolete/deprecated. > > The vfio-platform and vfio-amba drivers have an active maintainer, > but even the maintainer has no ability to test these drivers anymore. > The hardware itself has become obsolete and despite Eric's efforts to > add support for new devices and presenting on the complexities of > trying to manage and support shared resources at KVM Forum 2024, the > state of the driver and ability to test it upstream has not advanced. > The experiment has been useful, but seems to be reaching a conclusion. > QEMU intends to remove vfio-platform support in the 10.2 release. > Mark these drivers as obsolete/deprecated in the kernel as well. for the whole series: Reviewed-by: Eric Auger <eric.auger@redhat.com> Thanks Eric > > Thanks, > Alex > > Alex Williamson (2): > vfio/fsl-mc: Mark for removal > vfio/platform: Mark for removal > > MAINTAINERS | 4 ++-- > drivers/vfio/fsl-mc/Kconfig | 5 ++++- > drivers/vfio/fsl-mc/vfio_fsl_mc.c | 2 ++ > drivers/vfio/platform/Kconfig | 10 ++++++++-- > drivers/vfio/platform/reset/Kconfig | 6 +++--- > drivers/vfio/platform/vfio_amba.c | 2 ++ > drivers/vfio/platform/vfio_platform.c | 2 ++ > 7 files changed, 23 insertions(+), 8 deletions(-) > ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [PATCH 0/2] vfio: Deprecate fsl-mc, platform, and amba 2025-08-06 17:03 [PATCH 0/2] vfio: Deprecate fsl-mc, platform, and amba Alex Williamson ` (2 preceding siblings ...) 2025-08-07 8:12 ` [PATCH 0/2] vfio: Deprecate fsl-mc, platform, and amba Eric Auger @ 2025-08-11 20:23 ` Jason Gunthorpe 2025-08-15 14:47 ` Cédric Le Goater 4 siblings, 0 replies; 18+ messages in thread From: Jason Gunthorpe @ 2025-08-11 20:23 UTC (permalink / raw) To: Alex Williamson; +Cc: kvm, linux-kernel, eric.auger, clg On Wed, Aug 06, 2025 at 11:03:10AM -0600, Alex Williamson wrote: > The vfio-fsl-mc driver has been orphaned since April 2024 after the > maintainer became unresponsive. More than a year later, the driver > has only received community maintenance. Let's take the next step > towards removal by marking it obsolete/deprecated. > > The vfio-platform and vfio-amba drivers have an active maintainer, > but even the maintainer has no ability to test these drivers anymore. > The hardware itself has become obsolete and despite Eric's efforts to > add support for new devices and presenting on the complexities of > trying to manage and support shared resources at KVM Forum 2024, the > state of the driver and ability to test it upstream has not advanced. > The experiment has been useful, but seems to be reaching a conclusion. > QEMU intends to remove vfio-platform support in the 10.2 release. > Mark these drivers as obsolete/deprecated in the kernel as well. It seems fine, but I'd just remove them entirely right now. It is easy enough to revert a removal down the road if someone comes with a compelling reason. Reviewed-by: Jason Gunthorpe <jgg@nvidia.com> Jason ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [PATCH 0/2] vfio: Deprecate fsl-mc, platform, and amba 2025-08-06 17:03 [PATCH 0/2] vfio: Deprecate fsl-mc, platform, and amba Alex Williamson ` (3 preceding siblings ...) 2025-08-11 20:23 ` Jason Gunthorpe @ 2025-08-15 14:47 ` Cédric Le Goater 4 siblings, 0 replies; 18+ messages in thread From: Cédric Le Goater @ 2025-08-15 14:47 UTC (permalink / raw) To: Alex Williamson, kvm; +Cc: linux-kernel, eric.auger On 8/6/25 19:03, Alex Williamson wrote: > The vfio-fsl-mc driver has been orphaned since April 2024 after the > maintainer became unresponsive. More than a year later, the driver > has only received community maintenance. Let's take the next step > towards removal by marking it obsolete/deprecated. > > The vfio-platform and vfio-amba drivers have an active maintainer, > but even the maintainer has no ability to test these drivers anymore. > The hardware itself has become obsolete and despite Eric's efforts to > add support for new devices and presenting on the complexities of > trying to manage and support shared resources at KVM Forum 2024, the > state of the driver and ability to test it upstream has not advanced. > The experiment has been useful, but seems to be reaching a conclusion. > QEMU intends to remove vfio-platform support in the 10.2 release. > Mark these drivers as obsolete/deprecated in the kernel as well. > > Thanks, > Alex > > Alex Williamson (2): > vfio/fsl-mc: Mark for removal > vfio/platform: Mark for removal > > MAINTAINERS | 4 ++-- > drivers/vfio/fsl-mc/Kconfig | 5 ++++- > drivers/vfio/fsl-mc/vfio_fsl_mc.c | 2 ++ > drivers/vfio/platform/Kconfig | 10 ++++++++-- > drivers/vfio/platform/reset/Kconfig | 6 +++--- > drivers/vfio/platform/vfio_amba.c | 2 ++ > drivers/vfio/platform/vfio_platform.c | 2 ++ > 7 files changed, 23 insertions(+), 8 deletions(-) > Reviewed-by: Cédric Le Goater <clg@redhat.com> Thanks, C. ^ permalink raw reply [flat|nested] 18+ messages in thread
end of thread, other threads:[~2025-08-25 16:48 UTC | newest] Thread overview: 18+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2025-08-06 17:03 [PATCH 0/2] vfio: Deprecate fsl-mc, platform, and amba Alex Williamson 2025-08-06 17:03 ` [PATCH 1/2] vfio/fsl-mc: Mark for removal Alex Williamson 2025-08-15 10:02 ` Tian, Kevin 2025-08-06 17:03 ` [PATCH 2/2] vfio/platform: " Alex Williamson 2025-08-15 10:02 ` Tian, Kevin 2025-08-15 16:59 ` Mostafa Saleh 2025-08-18 16:52 ` Alex Williamson 2025-08-18 17:33 ` Mostafa Saleh 2025-08-19 9:58 ` Eric Auger 2025-08-20 15:20 ` Mostafa Saleh 2025-08-20 16:29 ` Eric Auger 2025-08-20 20:25 ` Mostafa Saleh 2025-08-25 13:48 ` Pranjal Shrivastava 2025-08-25 16:15 ` Alex Williamson 2025-08-25 16:48 ` Eric Auger 2025-08-07 8:12 ` [PATCH 0/2] vfio: Deprecate fsl-mc, platform, and amba Eric Auger 2025-08-11 20:23 ` Jason Gunthorpe 2025-08-15 14:47 ` Cédric Le Goater
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).