[PATCH 0/2] vfio: Restrict to 64-bit host platforms

[PATCH 0/2] vfio: Restrict to 64-bit host platforms

[Cédric Le Goater]

Hello,

This series avoids compiling VFIO on 32-bit host platforms where it is
not needed.

Thanks,

C.

Cédric Le Goater (2):
  vfio: Make vfio-pci available on 64-bit host platforms only
  vfio: Make vfio-platform available on Aarch64 platforms only

 hw/vfio/Kconfig | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

-- 
2.48.1

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

[Cédric Le Goater]

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)
 
 config VFIO_CCW
     bool
-- 
2.48.1

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

[BALATON Zoltan]

[-- Attachment #1: Type: text/plain, Size: 1277 bytes --]

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? I see PPC is defined in 
target/ppc/Kconfig so I think these mark the target not the host. Vfio-pci 
works with qemu-system-ppc and we are trying to use it for GPU pass 
through for 32 bit PPC guests. Please keep that enabled.

Regards,
BALATON Zoltan

> config VFIO_CCW
>     bool
>

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

[Cédric Le Goater]

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.

> I see PPC is defined in target/ppc/Kconfig so I think these mark the target not the host. Vfio-pci works with qemu-system-ppc 

Ah ! I am surprised. Which host and QEMU machine please ?

> and we are trying to use it for GPU pass through for 32 bit PPC guests. Please keep that enabled.

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.


Thanks,

C.



> 
> Regards,
> BALATON Zoltan
> 
>> config VFIO_CCW
>>     bool
>>

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

[BALATON Zoltan]

[-- Attachment #1: Type: text/plain, Size: 2215 bytes --]

On Wed, 26 Feb 2025, 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.

Where are these defined? I thought compiling qemu-system-ppc on x64_64 or 
aarch64 would have PPC defined not X86_64 or AARCH64 but I could well be 
missing something.

>> I see PPC is defined in target/ppc/Kconfig so I think these mark the target 
>> not the host. Vfio-pci works with qemu-system-ppc 
>
> Ah ! I am surprised. Which host and QEMU machine please ?

I've seen people do this on x86_64 host with pegasos2, amigaone and mac99 
running 32 bit guests (AmigaOS and MacOS). Some people running older 32 
bit Windows versions on pc machine might also use this.

>> and we are trying to use it for GPU pass through for 32 bit PPC guests. 
>> Please keep that enabled.
>
> 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.

That's about removing support for compiling QEMU on 32 bit host OSes not 
using 32 bit guests with qemu-system-ppc and qemu-system-i386 isn't it?

Regards,
BALATON Zoltan

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

[Philippe Mathieu-Daudé]

On 26/2/25 18:57, BALATON Zoltan wrote:
> On Wed, 26 Feb 2025, 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.
> 
> Where are these defined? I thought compiling qemu-system-ppc on x64_64 
> or aarch64 would have PPC defined not X86_64 or AARCH64 but I could well 
> be missing something.
> 
>>> I see PPC is defined in target/ppc/Kconfig so I think these mark the 
>>> target not the host. Vfio-pci works with qemu-system-ppc 
>>
>> Ah ! I am surprised. Which host and QEMU machine please ?
> 
> I've seen people do this on x86_64 host

Since this patch does:

   LINUX && PCI && (...  X86_64 ...)

these users won't see any change.

> with pegasos2, amigaone and 
> mac99 running 32 bit guests (AmigaOS and MacOS). Some people running 
> older 32 bit Windows versions on pc machine might also use this.
> 
>>> and we are trying to use it for GPU pass through for 32 bit PPC 
>>> guests. Please keep that enabled.
>>
>> 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.
> 
> That's about removing support for compiling QEMU on 32 bit host OSes not 
> using 32 bit guests with qemu-system-ppc and qemu-system-i386 isn't it?
> 
> Regards,
> BALATON Zoltan

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

[BALATON Zoltan]

[-- Attachment #1: Type: text/plain, Size: 2357 bytes --]

On Mon, 3 Mar 2025, Philippe Mathieu-Daudé wrote:
> On 26/2/25 18:57, BALATON Zoltan wrote:
>> On Wed, 26 Feb 2025, 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.
>> 
>> Where are these defined? I thought compiling qemu-system-ppc on x64_64 or 
>> aarch64 would have PPC defined not X86_64 or AARCH64 but I could well be 
>> missing something.
>> 
>>>> I see PPC is defined in target/ppc/Kconfig so I think these mark the 
>>>> target not the host. Vfio-pci works with qemu-system-ppc 
>>> 
>>> Ah ! I am surprised. Which host and QEMU machine please ?
>> 
>> I've seen people do this on x86_64 host
>
> Since this patch does:
>
>  LINUX && PCI && (...  X86_64 ...)
>
> these users won't see any change.

I still don't understand why. X86_64 is defined in target/i386/Kconfig. 
Isn't that only defined when building qemu-x86_64 or qemu-system-x86_64? 
Or is it also defined when building TCG on x86_64 host? This is confusing. 
docs/devel/tcg-ops.rst says "The TCG *target* is the architecture for 
which we generate the code. It is of course not the same as the "target" 
of QEMU which is the emulated architecture." Which of these is marked by 
these defines?

Regards,
BALATON Zoltan

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

[Paolo Bonzini]

On 3/3/25 15:30, Philippe Mathieu-Daudé wrote:
>>>> I see PPC is defined in target/ppc/Kconfig so I think these mark the 
>>>> target not the host. Vfio-pci works with qemu-system-ppc 
>>
>> I've seen people do this on x86_64 host
> 
> Since this patch does:
> 
>    LINUX && PCI && (...  X86_64 ...)
> 
> these users won't see any change.

This is wrong---clearly this patch was never tested on the 32-bit 
platforms where it was supposed to have an effect.

For VFIO_PLATFORM, no objections to deprecating this.

Paolo

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

[Cédric Le Goater]

On 3/3/25 15:46, Paolo Bonzini wrote:
> On 3/3/25 15:30, Philippe Mathieu-Daudé wrote:
>>>>> I see PPC is defined in target/ppc/Kconfig so I think these mark the target not the host. Vfio-pci works with qemu-system-ppc 
>>>
>>> I've seen people do this on x86_64 host
>>
>> Since this patch does:
>>
>>    LINUX && PCI && (...  X86_64 ...)
>>
>> these users won't see any change.
> 
> This is wrong---clearly this patch was never tested on the 32-bit platforms where it was supposed to have an effect.

euh it was.

With this patch, on 32-bit and 64-bit host systems :

   # build/qemu-system-i386 -device vfio-pci,?
   # qemu-system-i386: -device vfio-pci,?: Device 'vfio-pci' not found

Same for qemu-system-ppc and qemu-system-arm

What I am doing wrong ?

  
> For VFIO_PLATFORM, no objections to deprecating this.

Good let's do that !


Thanks,

C.

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

[BALATON Zoltan]

[-- Attachment #1: Type: text/plain, Size: 1186 bytes --]

On Mon, 3 Mar 2025, Cédric Le Goater wrote:
> On 3/3/25 15:46, Paolo Bonzini wrote:
>> On 3/3/25 15:30, Philippe Mathieu-Daudé wrote:
>>>>>> I see PPC is defined in target/ppc/Kconfig so I think these mark the 
>>>>>> target not the host. Vfio-pci works with qemu-system-ppc 
>>>> 
>>>> I've seen people do this on x86_64 host
>>> 
>>> Since this patch does:
>>> 
>>>    LINUX && PCI && (...  X86_64 ...)
>>> 
>>> these users won't see any change.
>> 
>> This is wrong---clearly this patch was never tested on the 32-bit platforms 
>> where it was supposed to have an effect.
>
> euh it was.
>
> With this patch, on 32-bit and 64-bit host systems :
>
>  # build/qemu-system-i386 -device vfio-pci,?
>  # qemu-system-i386: -device vfio-pci,?: Device 'vfio-pci' not found
>
> Same for qemu-system-ppc and qemu-system-arm
>
> What I am doing wrong ?

These QEMU targets aren't deprecated, compiling QEMU on 32 bit hosts is. 
But you can still use qemu-system-i386 and qemu-system-ppc on 64 bit 
hosts and vfio-pci works with these so it should not be disabled when 
building these QEMU targets. I think you meant to do something else not 
what this patch does.

Regards,
BALATON Zoltan

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

[Cédric Le Goater]

On 3/3/25 16:26, BALATON Zoltan wrote:
> On Mon, 3 Mar 2025, Cédric Le Goater wrote:
>> On 3/3/25 15:46, Paolo Bonzini wrote:
>>> On 3/3/25 15:30, Philippe Mathieu-Daudé wrote:
>>>>>>> I see PPC is defined in target/ppc/Kconfig so I think these mark the target not the host. Vfio-pci works with qemu-system-ppc 
>>>>>
>>>>> I've seen people do this on x86_64 host
>>>>
>>>> Since this patch does:
>>>>
>>>>    LINUX && PCI && (...  X86_64 ...)
>>>>
>>>> these users won't see any change.
>>>
>>> This is wrong---clearly this patch was never tested on the 32-bit platforms where it was supposed to have an effect.
>>
>> euh it was.
>>
>> With this patch, on 32-bit and 64-bit host systems :
>>
>>  # build/qemu-system-i386 -device vfio-pci,?
>>  # qemu-system-i386: -device vfio-pci,?: Device 'vfio-pci' not found
>>
>> Same for qemu-system-ppc and qemu-system-arm
>>
>> What I am doing wrong ?
> 
> These QEMU targets aren't deprecated, compiling QEMU on 32 bit hosts is. But you can still use qemu-system-i386 and qemu-system-ppc on 64 bit hosts and vfio-pci works with these so it should not be disabled when building these QEMU targets. I think you meant to do something else not what this patch does.

I meant to remove all VFIO devices on 32-bit host platforms (which
is not needed anymore since 32-bit host platforms are dying anyway).

The patch is actually doing more, as it is removing VFIO devices for
32-bit targets too. That said, I doubt this config is tested at all
on i386. Something to add on the TODO list.

Why are we keeping qemu-system-ppc and qemu-system-i386, and arm,
since qemu-system-ppc64 and qemu-system-x86_64 should be able to
run the same machines ?


Thanks,

C.





> 
> Regards,
> BALATON Zoltan

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

[Cédric Le Goater]

On 3/3/25 16:48, Cédric Le Goater wrote:
> On 3/3/25 16:26, BALATON Zoltan wrote:
>> On Mon, 3 Mar 2025, Cédric Le Goater wrote:
>>> On 3/3/25 15:46, Paolo Bonzini wrote:
>>>> On 3/3/25 15:30, Philippe Mathieu-Daudé wrote:
>>>>>>>> I see PPC is defined in target/ppc/Kconfig so I think these mark the target not the host. Vfio-pci works with qemu-system-ppc 
>>>>>>
>>>>>> I've seen people do this on x86_64 host
>>>>>
>>>>> Since this patch does:
>>>>>
>>>>>    LINUX && PCI && (...  X86_64 ...)
>>>>>
>>>>> these users won't see any change.
>>>>
>>>> This is wrong---clearly this patch was never tested on the 32-bit platforms where it was supposed to have an effect.
>>>
>>> euh it was.
>>>
>>> With this patch, on 32-bit and 64-bit host systems :
>>>
>>>  # build/qemu-system-i386 -device vfio-pci,?
>>>  # qemu-system-i386: -device vfio-pci,?: Device 'vfio-pci' not found
>>>
>>> Same for qemu-system-ppc and qemu-system-arm
>>>
>>> What I am doing wrong ?
>>
>> These QEMU targets aren't deprecated, compiling QEMU on 32 bit hosts is. But you can still use qemu-system-i386 and qemu-system-ppc on 64 bit hosts and vfio-pci works with these so it should not be disabled when building these QEMU targets. I think you meant to do something else not what this patch does.
> 
> I meant to remove all VFIO devices on 32-bit host platforms (which
> is not needed anymore since 32-bit host platforms are dying anyway).
> 
> The patch is actually doing more, as it is removing VFIO devices for
> 32-bit targets too. That said, I doubt this config is tested at all
> on i386. Something to add on the TODO list.

So,

     root@vm15:~# uname -a
     Linux vm15 6.10.12-686-pae #1 SMP PREEMPT_DYNAMIC Debian 6.10.12-1 (2024-10-01) i686 GNU/Linux
     root@vm15:~# lspci -s 0000:01:00.0 -v
     01:00.0 Ethernet controller: Intel Corporation Ethernet Virtual Function 700 Series (rev 02)
     	Subsystem: Intel Corporation Device 0000
     	Physical Slot: 0
     	Flags: bus master, fast devsel, latency 0
     	Memory at fba00000 (64-bit, prefetchable) [size=64K]
     	Memory at fba10000 (64-bit, prefetchable) [size=16K]
     	Capabilities: [70] MSI-X: Enable+ Count=5 Masked-
     	Capabilities: [a0] Express Endpoint, IntMsgNum 0
     	Capabilities: [100] Advanced Error Reporting
     	Capabilities: [1a0] Transaction Processing Hints
     	Capabilities: [1d0] Access Control Services
     	Kernel driver in use: iavf
     	Kernel modules: iavf
     root@vm15:~# ip link show dev enp1s0
     3: enp1s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP mode DEFAULT group default qlen 1000
         link/ether 06:0a:3d:59:01:11 brd ff:ff:ff:ff:ff:ff
         altname enx060a3d590111
     
It works well. I will make sure it continues to work.

Thanks,

C.

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

[Peter Maydell]

On Mon, 3 Mar 2025 at 15:49, Cédric Le Goater <clg@redhat.com> wrote:
> Why are we keeping qemu-system-ppc and qemu-system-i386, and arm,
> since qemu-system-ppc64 and qemu-system-x86_64 should be able to
> run the same machines ?

They're not identical -- for example "-cpu max" on
qemu-system-arm is a 32-bit CPU but on qemu-system-aarch64
it is a 64-bit CPU.

There's definitely a lot of overlap but we can't just drop
the -arm executable until/unless we figure out what to do
about the corner cases where they are different. Plus there's
a lot of users out there with existing command lines and
configs that assume the existence of a qemu-system-arm
executable.

thanks
-- PMM

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

[Philippe Mathieu-Daudé]

On 3/3/25 17:57, Peter Maydell wrote:
> On Mon, 3 Mar 2025 at 15:49, Cédric Le Goater <clg@redhat.com> wrote:
>> Why are we keeping qemu-system-ppc and qemu-system-i386, and arm,
>> since qemu-system-ppc64 and qemu-system-x86_64 should be able to
>> run the same machines ?
> 
> They're not identical -- for example "-cpu max" on
> qemu-system-arm is a 32-bit CPU but on qemu-system-aarch64
> it is a 64-bit CPU.
> 
> There's definitely a lot of overlap but we can't just drop
> the -arm executable until/unless we figure out what to do
> about the corner cases where they are different. Plus there's
> a lot of users out there with existing command lines and
> configs that assume the existence of a qemu-system-arm
> executable.

Thomas and myself have been trying to sort that out. Now with the
single-binary effort, it gained new interest. This hasn't be a trivial
task so far, due to as you mentioned the legacy CLI uses and migration.

This is however in my priority list and Alex asked to have a single
qemu-system-aarch64 binary for ARM/Aarch64 for the 11.0 release.

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

[Thomas Huth]

On 03/03/2025 18.32, Philippe Mathieu-Daudé wrote:
> On 3/3/25 17:57, Peter Maydell wrote:
>> On Mon, 3 Mar 2025 at 15:49, Cédric Le Goater <clg@redhat.com> wrote:
>>> Why are we keeping qemu-system-ppc and qemu-system-i386, and arm,
>>> since qemu-system-ppc64 and qemu-system-x86_64 should be able to
>>> run the same machines ?
>>
>> They're not identical -- for example "-cpu max" on
>> qemu-system-arm is a 32-bit CPU but on qemu-system-aarch64
>> it is a 64-bit CPU.
>>
>> There's definitely a lot of overlap but we can't just drop
>> the -arm executable until/unless we figure out what to do
>> about the corner cases where they are different. Plus there's
>> a lot of users out there with existing command lines and
>> configs that assume the existence of a qemu-system-arm
>> executable.
> 
> Thomas and myself have been trying to sort that out. Now with the
> single-binary effort, it gained new interest. This hasn't be a trivial
> task so far, due to as you mentioned the legacy CLI uses and migration.

FWIW, here's my former attempt to see whether we could move into that direction:

  https://lore.kernel.org/qemu-devel/20230425133851.489283-1-thuth@redhat.com/

In the end, it was too frustrating to struggle with the 
backwards-compatibility questions (do we really need to keep 
qemu-system-i386 around forever?), so I pretty much gave up on that patch 
series.

  Thomas

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

[BALATON Zoltan]

[-- Attachment #1: Type: text/plain, Size: 1926 bytes --]

On Wed, 5 Mar 2025, Thomas Huth wrote:
> On 03/03/2025 18.32, Philippe Mathieu-Daudé wrote:
>> On 3/3/25 17:57, Peter Maydell wrote:
>>> On Mon, 3 Mar 2025 at 15:49, Cédric Le Goater <clg@redhat.com> wrote:
>>>> Why are we keeping qemu-system-ppc and qemu-system-i386, and arm,
>>>> since qemu-system-ppc64 and qemu-system-x86_64 should be able to
>>>> run the same machines ?
>>> 
>>> They're not identical -- for example "-cpu max" on
>>> qemu-system-arm is a 32-bit CPU but on qemu-system-aarch64
>>> it is a 64-bit CPU.
>>> 
>>> There's definitely a lot of overlap but we can't just drop
>>> the -arm executable until/unless we figure out what to do
>>> about the corner cases where they are different. Plus there's
>>> a lot of users out there with existing command lines and
>>> configs that assume the existence of a qemu-system-arm
>>> executable.
>> 
>> Thomas and myself have been trying to sort that out. Now with the
>> single-binary effort, it gained new interest. This hasn't be a trivial
>> task so far, due to as you mentioned the legacy CLI uses and migration.
>
> FWIW, here's my former attempt to see whether we could move into that 
> direction:
>
> https://lore.kernel.org/qemu-devel/20230425133851.489283-1-thuth@redhat.com/

This mentions KVM compatibility. KVM now works at least on PowerPC G4 host 
with qemu-system-ppc (as I've heard, did not try it myself). Would that 
stop working with qemu-system-ppc64? As people still use old 32bit PPC 
OSes such as MacOS with qemu it's still wanted to keep it working. 
(Although most people use TCG on other hosts and maybe a few on actual PPC 
host but it's still nice to keep this feature until such hosts still 
exist.)

Regards,
BALATON Zoltan

> In the end, it was too frustrating to struggle with the 
> backwards-compatibility questions (do we really need to keep qemu-system-i386 
> around forever?), so I pretty much gave up on that patch series.

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

[Cédric Le Goater]

On 3/3/25 17:57, Peter Maydell wrote:
> On Mon, 3 Mar 2025 at 15:49, Cédric Le Goater <clg@redhat.com> wrote:
>> Why are we keeping qemu-system-ppc and qemu-system-i386, and arm,
>> since qemu-system-ppc64 and qemu-system-x86_64 should be able to
>> run the same machines ?
> 
> They're not identical -- for example "-cpu max" on
> qemu-system-arm is a 32-bit CPU but on qemu-system-aarch64
> it is a 64-bit CPU.

OK.

> There's definitely a lot of overlap but we can't just drop
> the -arm executable until/unless we figure out what to do
> about the corner cases where they are different. Plus there's
> a lot of users out there with existing command lines and
> configs that assume the existence of a qemu-system-arm
> executable.

We could have symlinks. Anyway, given the issue described
above, we need to keep a build for the 32-bit targets.

I see that qemu-system-arm supports virt machines. Would
you know if there is a supported userspace that I could use ?


Thanks,

C.

  

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

[Paolo Bonzini]

[-- Attachment #1: Type: text/plain, Size: 1351 bytes --]

Il lun 3 mar 2025, 16:05 Cédric Le Goater <clg@redhat.com> ha scritto:

> On 3/3/25 15:46, Paolo Bonzini wrote:
> > On 3/3/25 15:30, Philippe Mathieu-Daudé wrote:
> >>>>> I see PPC is defined in target/ppc/Kconfig so I think these mark the
> target not the host. Vfio-pci works with qemu-system-ppc
> >>>
> >>> I've seen people do this on x86_64 host
> >>
> >> Since this patch does:
> >>
> >>    LINUX && PCI && (...  X86_64 ...)
> >>
> >> these users won't see any change.
> >
> > This is wrong---clearly this patch was never tested on the 32-bit
> platforms where it was supposed to have an effect.
>
> euh it was.
>

Uff—I should have said was *only* tested on the 32-bit platforms where it
was supposed to have an effect! The problem is with the 64-bit hosts...

With this patch, on 32-bit and 64-bit host systems :
>
>    # build/qemu-system-i386 -device vfio-pci,?
>    # qemu-system-i386: -device vfio-pci,?: Device 'vfio-pci' not found
>
> Same for qemu-system-ppc and qemu-system-arm
>
> What I am doing wrong ?


... Where you were testing the wrong target. :) qemu-system-i386 should
still support VFIO if compiled on a 64-bit host, according to the subject.

Paolo


>
> > For VFIO_PLATFORM, no objections to deprecating this.
>
> Good let's do that !
>
>
> Thanks,
>
> C.
>
>
>
>

[-- Attachment #2: Type: text/html, Size: 2477 bytes --]

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

[Cédric Le Goater]

On 3/3/25 17:50, Paolo Bonzini wrote:
> 
> 
> Il lun 3 mar 2025, 16:05 Cédric Le Goater <clg@redhat.com <mailto:clg@redhat.com>> ha scritto:
> 
>     On 3/3/25 15:46, Paolo Bonzini wrote:
>      > On 3/3/25 15:30, Philippe Mathieu-Daudé wrote:
>      >>>>> I see PPC is defined in target/ppc/Kconfig so I think these mark the target not the host. Vfio-pci works with qemu-system-ppc
>      >>>
>      >>> I've seen people do this on x86_64 host
>      >>
>      >> Since this patch does:
>      >>
>      >>    LINUX && PCI && (...  X86_64 ...)
>      >>
>      >> these users won't see any change.
>      >
>      > This is wrong---clearly this patch was never tested on the 32-bit platforms where it was supposed to have an effect.
> 
>     euh it was.
> 
> 
> Uff—I should have said was *only* tested on the 32-bit platforms where it was supposed to have an effect! The problem is with the 64-bit hosts...
> 
>     With this patch, on 32-bit and 64-bit host systems :
> 
>         # build/qemu-system-i386 -device vfio-pci,?
>         # qemu-system-i386: -device vfio-pci,?: Device 'vfio-pci' not found
> 
>     Same for qemu-system-ppc and qemu-system-arm
> 
>     What I am doing wrong ?
> 
> 
> ... Where you were testing the wrong target. :) qemu-system-i386 should still support VFIO if compiled on a 64-bit host, according to the subject.

yep. I have a test case for it now ! on q35 and pc-i440fx machines.

Thanks,

C.

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

[Cédric Le Goater]

>>> I see PPC is defined in target/ppc/Kconfig so I think these mark the target not the host. Vfio-pci works with qemu-system-ppc 
>>
>> Ah ! I am surprised. Which host and QEMU machine please ?
> 
> I've seen people do this on x86_64 host with pegasos2, amigaone and mac99 running 32 bit guests (AmigaOS and MacOS). Some people running older 32 bit Windows versions on pc machine might also use this.


I tried with :

     qemu-system-ppc -m 1G -smp 1 -M mac99,via=pmu -cpu g4  ....

There are some errors/warnings:

     qemu-system-ppc: -device vfio-pci,host=0000:0c:00.0: warning: MSI-X is not supported by interrupt controller
     Cannot manage 'ethernet controller' PCI device type 'network':
     >>
     >>  8086 10c9 (2 0 0)
     >> set_property: NULL phandle
     
     >> =============================================================
     >> OpenBIOS 1.1 [Sep 24 2024 19:56]
     ...

but it does work :

     root@debian-powerpc:~# uname -a
     Linux debian-powerpc 6.1.0-7-powerpc #1 Debian 6.1.20-1 (2023-03-19) ppc GNU/Linux
     root@debian-powerpc:~# lspci -s  00:10.0 -vv
     00:10.0 Ethernet controller: Intel Corporation 82576 Gigabit Network Connection (rev 01)
     	Subsystem: Beijing Sinead Technology Co., Ltd. 82576 Gigabit Network Connection
     	Device tree node: /sys/firmware/devicetree/base/pci@f2000000/pci8086,10c9@10
     	Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr+ Stepping- SERR+ FastB2B- DisINTx-
     	Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
     	Latency: 0, Cache Line Size: 64 bytes
     	Interrupt: pin A routed to IRQ 27
     	Region 0: Memory at 82080000 (32-bit, non-prefetchable) [size=128K]
     	Region 1: Memory at 82400000 (32-bit, non-prefetchable) [size=4M]
     	Region 2: I/O ports at 1080 [size=32]
     	Region 3: Memory at 82800000 (32-bit, non-prefetchable) [size=16K]
     	Expansion ROM at 82c00000 [disabled] [size=4M]
     	Capabilities: [40] Power Management version 3
     		Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
     		Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=1 PME-
     	Capabilities: [a0] Express (v2) Endpoint, MSI 00
     		DevCap:	MaxPayload 512 bytes, PhantFunc 0, Latency L0s <512ns, L1 <64us
     			ExtTag- AttnBtn- AttnInd- PwrInd- RBE+ FLReset+ SlotPowerLimit 0W
     		DevCtl:	CorrErr- NonFatalErr- FatalErr+ UnsupReq-
     			RlxdOrd+ ExtTag- PhantFunc- AuxPwr- NoSnoop+ FLReset-
     			MaxPayload 256 bytes, MaxReadReq 512 bytes
     		DevSta:	CorrErr- NonFatalErr- FatalErr- UnsupReq- AuxPwr+ TransPend-
     		LnkCap:	Port #0, Speed 2.5GT/s, Width x4, ASPM L0s L1, Exit Latency L0s <4us, L1 <64us
     			ClockPM- Surprise- LLActRep- BwNot- ASPMOptComp-
     		LnkCtl:	ASPM L1 Enabled; RCB 64 bytes, Disabled- CommClk+
     			ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-
     		LnkSta:	Speed 2.5GT/s, Width x1 (downgraded)
     			TrErr- Train- SlotClk+ DLActive- BWMgmt- ABWMgmt-
     		DevCap2: Completion Timeout: Range ABCD, TimeoutDis+ NROPrPrP- LTR-
     			 10BitTagComp- 10BitTagReq- OBFF Not Supported, ExtFmt- EETLPPrefix-
     			 EmergencyPowerReduction Not Supported, EmergencyPowerReductionInit-
     			 FRS- TPHComp- ExtTPHComp-
     			 AtomicOpsCap: 32bit- 64bit- 128bitCAS-
     		DevCtl2: Completion Timeout: 16ms to 55ms, TimeoutDis- LTR- 10BitTagReq- OBFF Disabled,
     			 AtomicOpsCtl: ReqEn-
     		LnkSta2: Current De-emphasis Level: -6dB, EqualizationComplete- EqualizationPhase1-
     			 EqualizationPhase2- EqualizationPhase3- LinkEqualizationRequest-
     			 Retimer- 2Retimers- CrosslinkRes: unsupported
     	Kernel driver in use: igb
     	Kernel modules: igb
     root@debian-powerpc:~# ip link show dev enp0s16
     2: enp0s16: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP mode DEFAULT group default qlen 1000
         link/ether 80:61:5f:0a:2f:c4 brd ff:ff:ff:ff:ff:ff


The number of VFIO combinations drives me nuts. It's worse than PPC.

Thanks,

C.

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

[Paolo Bonzini]

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, 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.

Paolo

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

[Philippe Mathieu-Daudé]

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.

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

[Daniel P. Berrangé]

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 :|

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

[Cédric Le Goater]

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, 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

AFAICS, you can't build qemu-system-aarch64 on 32-bit ARM anymore. Can you ?

Thanks,

C.



> 
> 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.
> 
> Paolo
> 

[PATCH 2/2] vfio: Make vfio-platform available on Aarch64 platforms only

[Cédric Le Goater]

VFIO Platforms was designed for Aarch64. Restrict availability to
64-bit host platforms.

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 6ed825429a9151fcdff33e95d1a310210689b258..885630e8d30c656500fcd7dbb3f26a4c0113a17a 100644
--- a/hw/vfio/Kconfig
+++ b/hw/vfio/Kconfig
@@ -19,7 +19,7 @@ config VFIO_PLATFORM
     bool
     default y
     select VFIO
-    depends on LINUX && PLATFORM_BUS
+    depends on LINUX && PLATFORM_BUS && AARCH64
 
 config VFIO_XGMAC
     bool
-- 
2.48.1

Re: [PATCH 2/2] vfio: Make vfio-platform available on Aarch64 platforms only

[Eric Auger]

Hi Cédric,

On 2/26/25 9:47 AM, Cédric Le Goater wrote:
> VFIO Platforms was designed for Aarch64. Restrict availability to
> 64-bit host platforms.
>
> Cc: Eric Auger <eric.auger@redhat.com>
> Signed-off-by: Cédric Le Goater <clg@redhat.com>
Reviewed-by: Eric Auger <eric.auger@redhat.com>

As an outcome from last KVM forum, next step may be to simply remove
VFIO_PLATFORM from the qemu tree.

We also need to make a decision wrt linux vfio platform driver. As I
can't test it anymore without hacks (my last tegra234 mgbe works are
unlikely to land on qemu side and lack traction on kernel side too),
either someone who can test it volunteers to take over the kernel
maintainership or we remove it from kernel too.

Taking this opportunity to add Will, Marc, Peter in CC

Thanks

Eric
> ---
>  hw/vfio/Kconfig | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/hw/vfio/Kconfig b/hw/vfio/Kconfig
> index 6ed825429a9151fcdff33e95d1a310210689b258..885630e8d30c656500fcd7dbb3f26a4c0113a17a 100644
> --- a/hw/vfio/Kconfig
> +++ b/hw/vfio/Kconfig
> @@ -19,7 +19,7 @@ config VFIO_PLATFORM
>      bool
>      default y
>      select VFIO
> -    depends on LINUX && PLATFORM_BUS
> +    depends on LINUX && PLATFORM_BUS && AARCH64
>  
>  config VFIO_XGMAC
>      bool

Re: [PATCH 2/2] vfio: Make vfio-platform available on Aarch64 platforms only

[Alex Williamson]

On Thu, 27 Feb 2025 09:32:46 +0100
Eric Auger <eric.auger@redhat.com> wrote:

> Hi Cédric,
> 
> On 2/26/25 9:47 AM, Cédric Le Goater wrote:
> > VFIO Platforms was designed for Aarch64. Restrict availability to
> > 64-bit host platforms.
> >
> > Cc: Eric Auger <eric.auger@redhat.com>
> > Signed-off-by: Cédric Le Goater <clg@redhat.com>  
> Reviewed-by: Eric Auger <eric.auger@redhat.com>
> 
> As an outcome from last KVM forum, next step may be to simply remove
> VFIO_PLATFORM from the qemu tree.
> 
> We also need to make a decision wrt linux vfio platform driver. As I
> can't test it anymore without hacks (my last tegra234 mgbe works are
> unlikely to land on qemu side and lack traction on kernel side too),
> either someone who can test it volunteers to take over the kernel
> maintainership or we remove it from kernel too.

I think it's more than just a kernel maintainer stepping up to test,
there really needs to be some in-kernel justification for the
vfio-platform driver itself.  If it's only enabling out of tree use
cases and there's nothing in-tree that's actually independently
worthwhile, I don't really see why we shouldn't remove it and just let
those out of tree use cases provide their own out of tree versions of
vfio-platform.  Thanks,

Alex

Re: [PATCH 2/2] vfio: Make vfio-platform available on Aarch64 platforms only

[Philippe Mathieu-Daudé]

On 27/2/25 18:27, Alex Williamson wrote:
> On Thu, 27 Feb 2025 09:32:46 +0100
> Eric Auger <eric.auger@redhat.com> wrote:
> 
>> Hi Cédric,
>>
>> On 2/26/25 9:47 AM, Cédric Le Goater wrote:
>>> VFIO Platforms was designed for Aarch64. Restrict availability to
>>> 64-bit host platforms.
>>>
>>> Cc: Eric Auger <eric.auger@redhat.com>
>>> Signed-off-by: Cédric Le Goater <clg@redhat.com>
>> Reviewed-by: Eric Auger <eric.auger@redhat.com>

Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>

>> As an outcome from last KVM forum, next step may be to simply remove
>> VFIO_PLATFORM from the qemu tree.
>>
>> We also need to make a decision wrt linux vfio platform driver. As I
>> can't test it anymore without hacks (my last tegra234 mgbe works are
>> unlikely to land on qemu side and lack traction on kernel side too),
>> either someone who can test it volunteers to take over the kernel
>> maintainership or we remove it from kernel too.
> 
> I think it's more than just a kernel maintainer stepping up to test,
> there really needs to be some in-kernel justification for the
> vfio-platform driver itself.  If it's only enabling out of tree use
> cases and there's nothing in-tree that's actually independently
> worthwhile, I don't really see why we shouldn't remove it and just let
> those out of tree use cases provide their own out of tree versions of
> vfio-platform.  Thanks,

Now (1 week before freeze for release) is a good time to post a patch
deprecating it :)

Re: [PATCH 2/2] vfio: Make vfio-platform available on Aarch64 platforms only

[Eric Auger]

Hi,


On 3/3/25 3:32 PM, Philippe Mathieu-Daudé wrote:
> On 27/2/25 18:27, Alex Williamson wrote:
>> On Thu, 27 Feb 2025 09:32:46 +0100
>> Eric Auger <eric.auger@redhat.com> wrote:
>>
>>> Hi Cédric,
>>>
>>> On 2/26/25 9:47 AM, Cédric Le Goater wrote:
>>>> VFIO Platforms was designed for Aarch64. Restrict availability to
>>>> 64-bit host platforms.
>>>>
>>>> Cc: Eric Auger <eric.auger@redhat.com>
>>>> Signed-off-by: Cédric Le Goater <clg@redhat.com>
>>> Reviewed-by: Eric Auger <eric.auger@redhat.com>
>
> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
>
>>> As an outcome from last KVM forum, next step may be to simply remove
>>> VFIO_PLATFORM from the qemu tree.
>>>
>>> We also need to make a decision wrt linux vfio platform driver. As I
>>> can't test it anymore without hacks (my last tegra234 mgbe works are
>>> unlikely to land on qemu side and lack traction on kernel side too),
>>> either someone who can test it volunteers to take over the kernel
>>> maintainership or we remove it from kernel too.
>>
>> I think it's more than just a kernel maintainer stepping up to test,
>> there really needs to be some in-kernel justification for the
>> vfio-platform driver itself.  If it's only enabling out of tree use
>> cases and there's nothing in-tree that's actually independently
>> worthwhile, I don't really see why we shouldn't remove it and just let
>> those out of tree use cases provide their own out of tree versions of
>> vfio-platform.  Thanks,
>
> Now (1 week before freeze for release) is a good time to post a patch
> deprecating it :)
Yes I will do that tomorrow

Eric

Re: [PATCH 0/2] vfio: Restrict to 64-bit host platforms

[Daniel P. Berrangé]

On Wed, Feb 26, 2025 at 09:47:19AM +0100, Cédric Le Goater wrote:
> Hello,
> 
> This series avoids compiling VFIO on 32-bit host platforms where it is
> not needed.

If it was previously enabled on 32-bit and was possible to successfully
build & use, then it needs to go through the deprecation process - we
can't just rip out features with no prior warning.

In any case this recently merged:

  commit 6d701c9bac1d3571e9ad511e01b27df7237f0b13
  Author: Richard Henderson <richard.henderson@linaro.org>
  Date:   Mon Jan 27 16:22:24 2025 -0800

    meson: Deprecate 32-bit host support
    
    We deprecated i686 system mode support for qemu 8.0.  However, to
    make real cleanups to TCG we need to deprecate all 32-bit hosts.

so 32-bit host support in general is nearing end of life. Given that,
I don't think we need to further limit 32-bit host for individual
features, just let it die all at once.


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 :|

Re: [PATCH 0/2] vfio: Restrict to 64-bit host platforms

[Cédric Le Goater]

Hello

On 2/26/25 15:01, Daniel P. Berrangé wrote:
> On Wed, Feb 26, 2025 at 09:47:19AM +0100, Cédric Le Goater wrote:
>> Hello,
>>
>> This series avoids compiling VFIO on 32-bit host platforms where it is
>> not needed.
> 
> If it was previously enabled on 32-bit and was possible to successfully
> build & use, then it needs to go through the deprecation process - we
> can't just rip out features with no prior warning.

well, x86 32-bit was the host platform I was not sure about and Alex
confirmed it worked. We would need deprecation for it I agree.
  
> In any case this recently merged:
> 
>    commit 6d701c9bac1d3571e9ad511e01b27df7237f0b13
>    Author: Richard Henderson <richard.henderson@linaro.org>
>    Date:   Mon Jan 27 16:22:24 2025 -0800
> 
>      meson: Deprecate 32-bit host support
>      
>      We deprecated i686 system mode support for qemu 8.0.  However, to
>      make real cleanups to TCG we need to deprecate all 32-bit hosts.

oh. I missed that. Great, at last !

> so 32-bit host support in general is nearing end of life. Given that,
> I don't think we need to further limit 32-bit host for individual
> features, just let it die all at once.

yes. Let's do that.

Now, I have to look more closely at those patches modifying VFIO for
32-bit support.

Thanks,

C.