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 <hars...@linux.ibm.com> > > > > > Cc: Tony Krowiak <akrow...@linux.ibm.com> > > > > > Cc: Eric Farman <far...@linux.ibm.com> > > > > > Cc: Eric Auger <eric.au...@redhat.com> > > > > > Signed-off-by: Cédric Le Goater <c...@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 :|
