> 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.
A more generic solution might be to fully virtualize the PHY. Let the
host kernel drive the PHY, and QEMU can use /sys/bus/mdio_bus/devices,
and uevents sent to user space. Ioana already added support for a PHY
not bound to a MAC in phylink. You would need to add a UAPI for
start/stop, and maybe a couple more operations, and probably export a
bit more information.
This would then solve the quad PHY situation, and any other odd
setups. And all the VM would require is genphy, keeping it simple.
Andrew
