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: <20200709233337.xxneb7kweayr4yis@skbuf>
Date:   Fri, 10 Jul 2020 02:33:37 +0300
From:   Vladimir Oltean <olteanv@...il.com>
To:     Andrew Lunn <andrew@...n.ch>
Cc:     Tobias Waldekranz <tobias@...dekranz.com>, netdev@...r.kernel.org,
        f.fainelli@...il.com, hkallweit1@...il.com
Subject: Re: MDIO Debug Interface

On Fri, Jul 10, 2020 at 01:20:35AM +0200, Andrew Lunn wrote:
> > 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

The MAC driver is also in the VM, yes, and the VM can be given
pass-through access to the MAC register map. But the PHY is on a shared
bus. It is not desirable to give the VM access to the entire MDIO
controller's register map, for a number of reasons which I'm sure I
don't need to enumerate. So QEMU should be instructed which PHY should
each network interface use and on which bus, and it should fix-up the
device tree of the guest with a phy-handle to a PHY on a
para-virtualized MDIO bus, guest-side driver of which is going to be
accessing the real MDIO bus through this UAPI which we're talking about.
Then the host-side MDIO driver can ensure serialization of MDIO
accesses, etc etc.

It's been a while since I looked at this, so I may be lacking some of
the technical details, and brushing them up is definitely not something
for today.

-Vladimir