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
