netdev - Re: MDIO Debug Interface

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: <20200709232035.GE1014141@lunn.ch>
Date:   Fri, 10 Jul 2020 01:20:35 +0200
From:   Andrew Lunn <andrew@...n.ch>
To:     Vladimir Oltean <olteanv@...il.com>
Cc:     Tobias Waldekranz <tobias@...dekranz.com>, netdev@...r.kernel.org,
        f.fainelli@...il.com, hkallweit1@...il.com
Subject: Re: MDIO Debug Interface

> Fear not, the lack of a mainline UAPI for MDIO access will not prevent
> any vendor from adding a sysfs mdio_read and mdio_write, if they need it
> for their user space SDK :)

They do. But it means you have to use their kernel, or at least their
kernel module. That will put off some people. But if they can claim it
works on any kernel after v5.9, it makes the marketing much easier.

Like i said, it is a trade off.

> Virtualization is a reasonable use case in my opinion and it would
> need something like this, for the guest kernel to have access to its
> PHY.

And i would like a better understanding of this use case. It seems odd
you are putting the driver for a PHY in the VM. Is the MAC driver also
in the VM? As you said, VM context switches are expensive, so it would
seem to make more sense to let the host drive the hardware, which it
can do without all these context switches, and export a much simpler
and efficient API to the VM.

    Andrew