Re: MDIO Debug Interface

[Vladimir Oltean <olteanv@gmail.com>]

Hi Tobias,

On Fri, Jul 10, 2020 at 11:30:21AM +0200, Tobias Waldekranz wrote:
> On Fri Jul 10, 2020 at 4:33 AM CEST, Vladimir Oltean wrote:
> > 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
> 
> Have you considered the case where the PHY is only a slice of a quad-
> or octal PHY?
> 
> I know that on at least some of these chips, all slices have access to
> global registers that can have destructive effects on neighboring
> slices. That could make it very difficult to implement a secure
> solution using this architecture.

You raise a good point. Some quad PHYs have a sane design which is
easier to virtualize and some have a less sane design.

In principle there is nothing in this para-virtualization design that
would preclude a quirky quad PHY from being accessed in a
virtualization-safe mode. The main use case for PHY access in a VM is
for detecting when the link went down. Worst case, the QEMU host-side
driver could lie about the PHY ID, and could only expose the clause 22
subset of registers that could make it compatible with genphy. I don't
think this changes the overall approach about how MDIO devices would be
virtualized with QEMU.

Thanks,
-Vladimir