Hi Eric,
On 5/3/25 11:58, Eric Auger wrote:
As an outcome of KVM forum 2024 "vfio-platform: live and let die?"
talk, let's deprecate vfio-platform devices.
Signed-off-by: Eric Auger <eric.au...@redhat.com>
---
docs/about/deprecated.rst | 25 +++++++++++++++++++++++++
hw/vfio/amd-xgbe.c | 2 ++
hw/vfio/calxeda-xgmac.c | 2 ++
hw/vfio/platform.c | 1 +
4 files changed, 30 insertions(+)
diff --git a/docs/about/deprecated.rst b/docs/about/deprecated.rst
index abadf8de27..d11a7004df 100644
--- a/docs/about/deprecated.rst
+++ b/docs/about/deprecated.rst
@@ -434,6 +434,31 @@ Stream ``reconnect`` (since 9.2)
The ``reconnect`` option only allows specifiying second granularity timeouts,
which is not enough for all types of use cases, use ``reconnect-ms`` instead.
+VFIO device options
+''''''''''''''''''
+
+``-device vfio-calxeda-xgmac`` (since v2.4)
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
"since" in this file means "since when the option is deprecated",
so it should be "since 10.0".
+The vfio-calxeda-xgmac device allows to assign a host Calxeda Highbank
+10Gb XGMAC Ethernet controller device ("calxeda,hb-xgmac" compatibility
+string) to a guest. Calxeda HW has been ewasted now and there is no point
+keeping that device.
+
+``-device vfio-amd-xgbe`` (since v2.6)
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Ditto.
+The vfio-amd-xgbe devices allows to assign a host AMD 10GbE controller
+to a guest ("amd,xgbe-seattle-v1a" compatibility string). AMD "Seattle"
+is not supported anymore and there is no point keeping that device.
+
+``-device vfio-platform`` (since v3.1)
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Ditto.
+The vfio-platform device allows to assign a host platform device
+to a guest in a generic manner. Integrating a new device into
+the vfio-platform infrastructure requires some adaptation at
+both kernel and qemu level. No such attempt has been done for years
+and the conclusion is that vfio-platform has not got any traction.
+PCIe passthrough shall be the mainline solution.
