[PATCH] net/mlx5: fix hypervisor detection in VLAN workaround

[PATCH] net/mlx5: fix hypervisor detection in VLAN workaround

[Viacheslav Ovsiienko]

The mlx5 PMD provides a specific workaround for the VMware ESXi
hypervisor, enabling on-demand routing configuration to virtual
machines. This workaround activates when the device type is
a Virtual Function and either an ESXi hypervisor is detected
or the hypervisor type is unknown.

For non-x86 architectures the function rte_hypervisor_get()
consistently returns an unknown type, which triggers the workaround
automatically without any actual needs. If there are VLAN support
requirements, this can lead to failures in inserting default control
flows.

Do not trigger the workaround for unknown hypervisor type
in non-x86 environments.

Fixes: dfedf3e3f9d2 ("net/mlx5: add workaround for VLAN in virtual machine")
Cc: stable@dpdk.org

Signed-off-by: Viacheslav Ovsiienko <viacheslavo@nvidia.com>
---
 drivers/net/mlx5/linux/mlx5_vlan_os.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/net/mlx5/linux/mlx5_vlan_os.c b/drivers/net/mlx5/linux/mlx5_vlan_os.c
index 81611a8d3f..017953d5cc 100644
--- a/drivers/net/mlx5/linux/mlx5_vlan_os.c
+++ b/drivers/net/mlx5/linux/mlx5_vlan_os.c
@@ -112,7 +112,9 @@ mlx5_vlan_vmwa_init(struct rte_eth_dev *dev, uint32_t ifindex)
 	/* Check whether there is desired virtual environment */
 	hv_type = rte_hypervisor_get();
 	switch (hv_type) {
+#if defined(RTE_ARCH_X86) || defined(RTE_ARCH_X86_64)
 	case RTE_HYPERVISOR_UNKNOWN:
+#endif
 	case RTE_HYPERVISOR_VMWARE:
 		/*
 		 * The "white list" of configurations
-- 
2.34.1

Re: [PATCH] net/mlx5: fix hypervisor detection in VLAN workaround

[Stephen Hemminger]

On Tue, 3 Dec 2024 18:22:00 +0200
Viacheslav Ovsiienko <viacheslavo@nvidia.com> wrote:

> diff --git a/drivers/net/mlx5/linux/mlx5_vlan_os.c b/drivers/net/mlx5/linux/mlx5_vlan_os.c
> index 81611a8d3f..017953d5cc 100644
> --- a/drivers/net/mlx5/linux/mlx5_vlan_os.c
> +++ b/drivers/net/mlx5/linux/mlx5_vlan_os.c
> @@ -112,7 +112,9 @@ mlx5_vlan_vmwa_init(struct rte_eth_dev *dev, uint32_t ifindex)
>  	/* Check whether there is desired virtual environment */
>  	hv_type = rte_hypervisor_get();
>  	switch (hv_type) {
> +#if defined(RTE_ARCH_X86) || defined(RTE_ARCH_X86_64)
>  	case RTE_HYPERVISOR_UNKNOWN:
> +#endif
>  	case RTE_HYPERVISOR_VMWARE:
>  		/*
>  		 * The "white list" of configurations

Could you fix that comment as well?
We got rid of all use of "whitelist" in DPDK, looks like this one got missed.

[PATCH v2] net/mlx5: fix hypervisor detection in VLAN workaround

[Viacheslav Ovsiienko]

The mlx5 PMD provides a specific workaround for the VMware ESXi
hypervisor, enabling on-demand routing configuration to virtual
machines. This workaround activates when the device type is
a Virtual Function and either an ESXi hypervisor is detected
or the hypervisor type is unknown.

For non-x86 architectures the function rte_hypervisor_get()
consistently returns an unknown type, which triggers the workaround
automatically without any actual needs. If there are VLAN support
requirements, this can lead to failures in inserting default control
flows.

Do not trigger the workaround for unknown hypervisor type
in non-x86 environments.

Fixes: dfedf3e3f9d2 ("net/mlx5: add workaround for VLAN in virtual machine")
Cc: stable@dpdk.org

Signed-off-by: Viacheslav Ovsiienko <viacheslavo@nvidia.com>

--
v2: updated cooments to remove "white list"
---
 drivers/net/mlx5/linux/mlx5_vlan_os.c | 10 +++++-----
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/drivers/net/mlx5/linux/mlx5_vlan_os.c b/drivers/net/mlx5/linux/mlx5_vlan_os.c
index 81611a8d3f..353484de3f 100644
--- a/drivers/net/mlx5/linux/mlx5_vlan_os.c
+++ b/drivers/net/mlx5/linux/mlx5_vlan_os.c
@@ -112,16 +112,16 @@ mlx5_vlan_vmwa_init(struct rte_eth_dev *dev, uint32_t ifindex)
 	/* Check whether there is desired virtual environment */
 	hv_type = rte_hypervisor_get();
 	switch (hv_type) {
+#if defined(RTE_ARCH_X86) || defined(RTE_ARCH_X86_64)
+	/* Always misdetected on ARM archs, let's ignore this */
 	case RTE_HYPERVISOR_UNKNOWN:
+#endif
 	case RTE_HYPERVISOR_VMWARE:
-		/*
-		 * The "white list" of configurations
-		 * to engage the workaround.
-		 */
+		/* The list of configurations to engage the workaround. */
 		break;
 	default:
 		/*
-		 * The configuration is not found in the "white list".
+		 * The configuration is not found in the list.
 		 * We should not engage the VLAN workaround.
 		 */
 		return NULL;
-- 
2.34.1

Re: [PATCH v2] net/mlx5: fix hypervisor detection in VLAN workaround

[Thomas Monjalon]

06/12/2024 15:26, Viacheslav Ovsiienko:
> The mlx5 PMD provides a specific workaround for the VMware ESXi
> hypervisor, enabling on-demand routing configuration to virtual
> machines. This workaround activates when the device type is
> a Virtual Function and either an ESXi hypervisor is detected
> or the hypervisor type is unknown.
> 
> For non-x86 architectures the function rte_hypervisor_get()
> consistently returns an unknown type, which triggers the workaround
> automatically without any actual needs. If there are VLAN support
> requirements, this can lead to failures in inserting default control
> flows.
> 
> Do not trigger the workaround for unknown hypervisor type
> in non-x86 environments.

It would be a lot better to fix rte_hypervisor_get().
I suggest starting with the read of /sys/class/dmi/id/

Re: [PATCH v2] net/mlx5: fix hypervisor detection in VLAN workaround

[Stephen Hemminger]

On Thu, 12 Dec 2024 11:52:51 +0100
Thomas Monjalon <thomas@monjalon.net> wrote:

> 06/12/2024 15:26, Viacheslav Ovsiienko:
> > The mlx5 PMD provides a specific workaround for the VMware ESXi
> > hypervisor, enabling on-demand routing configuration to virtual
> > machines. This workaround activates when the device type is
> > a Virtual Function and either an ESXi hypervisor is detected
> > or the hypervisor type is unknown.
> > 
> > For non-x86 architectures the function rte_hypervisor_get()
> > consistently returns an unknown type, which triggers the workaround
> > automatically without any actual needs. If there are VLAN support
> > requirements, this can lead to failures in inserting default control
> > flows.
> > 
> > Do not trigger the workaround for unknown hypervisor type
> > in non-x86 environments.  
> 
> It would be a lot better to fix rte_hypervisor_get().
> I suggest starting with the read of /sys/class/dmi/id/

The common heuristic is what is in the lscpu utility.
	https://github.com/util-linux/util-linux/sys-utils/lscpu-virt.c

Doing all this right is complex.

PS: it should also detect Xen and others even though DPDK doesn' support it.