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
