Message-ID: <aKNj4EUgHYCZ9Q4f@google.com>
Date: Mon, 18 Aug 2025 17:33:20 +0000
From: Mostafa Saleh <smostafa@...gle.com>
To: Alex Williamson <alex.williamson@...hat.com>
Cc: kvm@...r.kernel.org, linux-kernel@...r.kernel.org,
	eric.auger@...hat.com, clg@...hat.com
Subject: Re: [PATCH 2/2] vfio/platform: Mark for removal

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@...gle.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
> 

Powered by blists - more mailing lists