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

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

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

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

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