Re: [PATCH 1/2] vfio: Make vfio-pci available on 64-bit host platforms only

["Daniel P. Berrangé" <berrange@redhat.com>]

On Mon, Mar 03, 2025 at 03:53:29PM +0100, Philippe Mathieu-Daudé wrote:
> On 3/3/25 15:43, Paolo Bonzini wrote:
> > On 2/26/25 17:26, Cédric Le Goater wrote:
> > > On 2/26/25 15:12, BALATON Zoltan wrote:
> > > > On Wed, 26 Feb 2025, Cédric Le Goater wrote:
> > > > > VFIO PCI never worked on PPC32 nor ARM, S390x is 64-bit, it might have
> > > > > worked on i386 long ago but we have no plans to further support VFIO
> > > > > on any 32-bit host platforms. Restrict to 64-bit host platforms.
> > > > > 
> > > > > Cc: Harsh Prateek Bora <harshpb@linux.ibm.com>
> > > > > Cc: Tony Krowiak <akrowiak@linux.ibm.com>
> > > > > Cc: Eric Farman <farman@linux.ibm.com>
> > > > > Cc: Eric Auger <eric.auger@redhat.com>
> > > > > Signed-off-by: Cédric Le Goater <clg@redhat.com>
> > > > > ---
> > > > > hw/vfio/Kconfig | 2 +-
> > > > > 1 file changed, 1 insertion(+), 1 deletion(-)
> > > > > 
> > > > > diff --git a/hw/vfio/Kconfig b/hw/vfio/Kconfig
> > > > > index 7cdba0560aa821c88d3420b36f86020575834202..6ed825429a9151fcdff33e95d1a310210689b258
> > > > > 100644
> > > > > --- a/hw/vfio/Kconfig
> > > > > +++ b/hw/vfio/Kconfig
> > > > > @@ -7,7 +7,7 @@ config VFIO_PCI
> > > > >     default y
> > > > >     select VFIO
> > > > >     select EDID
> > > > > -    depends on LINUX && PCI
> > > > > +    depends on LINUX && PCI && (AARCH64 || PPC64 || X86_64 || S390X)
> > > > 
> > > > Are these defined for the host or target?
> > > 
> > > host.
> > 
> > No, Zoltan is correct.  They are defined for the target,
> 
> Oops indeed, not my day.
> 
> > so if you build for 32-bit ARM you'd still get things with "depends on
> > AARCH64" in qemu- system-aarch64.  You can check that you have
> > 
> > config SBSA_REF
> >      bool
> >      default y
> >      depends on TCG && AARCH64
> > 
> > but on x86-64:
> > 
> > $ qemu-system-aarch64 -M help|grep sbsa
> > sbsa-ref             QEMU 'SBSA Reference' ARM Virtual Machine
> > 
> > 
> > > As per commit 6d701c9bac1d3571e9ad511e01b27df7237f0b13 "meson: Deprecate
> > > 32-bit host support", support will be fully removed in 2 releases and
> > > it doesn't need to be addressed by VFIO.
> > 
> > Note that a deprecation *allows* full removal in 2 releases.  We have a
> > lot of things that are deprecated but have not been removed.  For
> > example
> > 
> >     Short-form boolean options (since 6.0)
> >     ''''''''''''''''''''''''''''''''''''''
> > 
> >     Boolean options such as ``share=on``/``share=off`` could be written
> >     in short form as ``share`` and ``noshare``.  This is now deprecated
> >     and will cause a warning.
> > 
> > is deprecated to *allow* switching command-line options from the "qemu-
> > options" parser to the "keyval" parser that doesn't support short-form
> > boolean options, but it's unlikely that qemu-options will drop support
> > for short-form boolean options.
> 
> In another thread Daniel said deprecated options shall be removed, the
> only justification for delay being man power, IIRC.

Right, after 2 releases a deprecated thing is open to deletion.

Deleting still requires someone to do the work though, so we end up with
things living longer than the 2 release deprecation period until someone
with motivation comes along to do the deletion. 

If we change our mind & truly don't want to delete something, then the
deprecation notice is supposed to be removed, not left around forever.

With regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|