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

["Philippe Mathieu-Daudé" <philmd@linaro.org>]

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.