netdev - Re: [PATCH net-next v2 12/14] sfc: set EF100 VF MAC address through representor

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <bfc03b98-53ce-077a-4627-6c8d51a29e08@gmail.com>
Date:   Thu, 28 Jul 2022 19:54:21 +0100
From:   Edward Cree <ecree.xilinx@...il.com>
To:     Jakub Kicinski <kuba@...nel.org>
Cc:     ecree@...inx.com, davem@...emloft.net, pabeni@...hat.com,
        linux-net-drivers@....com, netdev@...r.kernel.org
Subject: Re: [PATCH net-next v2 12/14] sfc: set EF100 VF MAC address through
 representor

On 28/07/2022 19:32, Jakub Kicinski wrote:
> IIRC the reprs are all linked to the PCI device of the PF in sysfs,
You mean /sys/class/net/$VFREP/device?  On sfc that's (intentionally)
 nonexistent; the only visible connection between repr and its owning
 PF is /sys/class/net/$VFREP/phys_switch_id which holds the same
 value as /sys/class/net/$PF/phys_port_id.

> How do you map reprs to VFs? The PCI devices of the VF may be on 
> a different system.
That's what the client ID from patch #10 is for.  We ask the FW for
 a handle to "caller's PCIe controller → caller's PF → VF number
 efv->idx", and that handle is what we store in efv->clid, and later
 pass to MC_CMD_SET_CLIENT_MAC_ADDRESSES in patch #12.

The user determines which repr corresponds to which VF by looking in
 /sys/class/net/$VFREP/phys_port_name (e.g. "p0pf0vf0").

> But reps are like switch ports in a switch ASIC, and the PCI
> device is the other side of the virtual wire. You would not be
> configuring the MAC address of a peer to peer link by setting 
> the local address.
Indeed.  I agree that .ndo_set_mac_address() is the wrong interface.
But the interface I have in mind would be something like
    int (*ndo_set_partner_mac_address)(struct net_device *, void *);
 and would only be implemented by representor netdevs.
Idk what the uAPI/UI for that would be; probably a new `ip link set`
 parameter.

-ed