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

[Thomas Monjalon <thomas@monjalon.net>]

12/12/2024 18:27, 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.

I don't think we need to detect all.
Currently we have a very limited implementation, using only CPUID on x86.