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

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
>

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

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

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
> 

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.

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

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

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

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

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

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.

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

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.

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

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

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

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.

  

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.

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

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.

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.

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