[PATCH] hw/arm: Deprecate legacy VirtIO devices on big-endian guests
We couldn't find a way (guest OS with VirtIO drivers) to test a legacy VirtIO device on a ARM vCPU running in big-endian. Deprecate for the v11.0 release, giving 1 year to users who really care to contribute functional tests. Suggested-by: Alex Bennée <alex.bennee@linaro.org> Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org> --- docs/about/deprecated.rst | 11 +++++++++++ 1 file changed, 11 insertions(+) diff --git a/docs/about/deprecated.rst b/docs/about/deprecated.rst index ac31a2bce42..3a69facb0f1 100644 --- a/docs/about/deprecated.rst +++ b/docs/about/deprecated.rst @@ -515,6 +515,17 @@ It was implemented as a no-op instruction in TCG up to QEMU 9.0, but only with ``-cpu max`` (which does not guarantee migration compatibility across versions). +VirtIO devices +'''''''''''''' + +Legacy VirtIO devices on Big-Endian ARM architecture (since 11.0) +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +There are no functional tests for legacy virtio devices used by ARM +machines running in big-endian order, which makes harder to maintain +the code path while the code base evolve. + + Backwards compatibility ----------------------- -- 2.52.0
On Wed, Dec 17, 2025 at 4:07 PM Philippe Mathieu-Daudé <philmd@linaro.org> wrote:
We couldn't find a way (guest OS with VirtIO drivers) to test a legacy VirtIO device on a ARM vCPU running in big-endian.
Deprecate for the v11.0 release, giving 1 year to users who really care to contribute functional tests.
Suggested-by: Alex Bennée <alex.bennee@linaro.org> Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org> --- docs/about/deprecated.rst | 11 +++++++++++ 1 file changed, 11 insertions(+)
diff --git a/docs/about/deprecated.rst b/docs/about/deprecated.rst index ac31a2bce42..3a69facb0f1 100644 --- a/docs/about/deprecated.rst +++ b/docs/about/deprecated.rst @@ -515,6 +515,17 @@ It was implemented as a no-op instruction in TCG up to QEMU 9.0, but only with ``-cpu max`` (which does not guarantee migration compatibility across versions).
+VirtIO devices +'''''''''''''' + +Legacy VirtIO devices on Big-Endian ARM architecture (since 11.0) +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +There are no functional tests for legacy virtio devices used by ARM +machines running in big-endian order, which makes harder to maintain
Nit: s/makes/makes it/
+the code path while the code base evolve.
s/evolve/evolves Reviewed-by: Manos Pitsidianakis <manos.pitsidianakis@linaro.org>
+ + Backwards compatibility -----------------------
-- 2.52.0
On Wed, Dec 17, 2025 at 03:06:57PM +0100, Philippe Mathieu-Daudé wrote:
We couldn't find a way (guest OS with VirtIO drivers) to test a legacy VirtIO device on a ARM vCPU running in big-endian.
Deprecate for the v11.0 release, giving 1 year to users who really care to contribute functional tests.
Suggested-by: Alex Bennée <alex.bennee@linaro.org> Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org> --- docs/about/deprecated.rst | 11 +++++++++++ 1 file changed, 11 insertions(+)
diff --git a/docs/about/deprecated.rst b/docs/about/deprecated.rst index ac31a2bce42..3a69facb0f1 100644 --- a/docs/about/deprecated.rst +++ b/docs/about/deprecated.rst @@ -515,6 +515,17 @@ It was implemented as a no-op instruction in TCG up to QEMU 9.0, but only with ``-cpu max`` (which does not guarantee migration compatibility across versions).
+VirtIO devices +'''''''''''''' + +Legacy VirtIO devices on Big-Endian ARM architecture (since 11.0) +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +There are no functional tests for legacy virtio devices used by ARM +machines running in big-endian order, which makes harder to maintain +the code path while the code base evolve.
Lack of test coverage is not a reason to deprecate something. We deprecate things we intend to intentionally remove or intentionally change in an incompatible manner. If something is not tested, that merely means it has lesser quality guarantees, and is liable to unintenionally get broken at times. If we're planning to *intentionally* remove the ability to use legacy virtio on big endian, that would be a reason to deprecate. If so the deprecation message should say this, not talk about missing functional testing. With regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
Daniel P. Berrangé <berrange@redhat.com> writes:
On Wed, Dec 17, 2025 at 03:06:57PM +0100, Philippe Mathieu-Daudé wrote:
We couldn't find a way (guest OS with VirtIO drivers) to test a legacy VirtIO device on a ARM vCPU running in big-endian.
Deprecate for the v11.0 release, giving 1 year to users who really care to contribute functional tests.
Suggested-by: Alex Bennée <alex.bennee@linaro.org> Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org> --- docs/about/deprecated.rst | 11 +++++++++++ 1 file changed, 11 insertions(+)
diff --git a/docs/about/deprecated.rst b/docs/about/deprecated.rst index ac31a2bce42..3a69facb0f1 100644 --- a/docs/about/deprecated.rst +++ b/docs/about/deprecated.rst @@ -515,6 +515,17 @@ It was implemented as a no-op instruction in TCG up to QEMU 9.0, but only with ``-cpu max`` (which does not guarantee migration compatibility across versions).
+VirtIO devices +'''''''''''''' + +Legacy VirtIO devices on Big-Endian ARM architecture (since 11.0) +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +There are no functional tests for legacy virtio devices used by ARM +machines running in big-endian order, which makes harder to maintain +the code path while the code base evolve.
Lack of test coverage is not a reason to deprecate something.
We deprecate things we intend to intentionally remove or intentionally change in an incompatible manner.
We also deprecate things that stop us moving the code forward. c.f. the long process to deprecate 32 bit hosts.
If something is not tested, that merely means it has lesser quality guarantees, and is liable to unintenionally get broken at times.
If we're planning to *intentionally* remove the ability to use legacy virtio on big endian, that would be a reason to deprecate. If so the deprecation message should say this, not talk about missing functional testing.
As far as I'm aware BE Arm is a very small niche and I'm not even sure anyone runs BE Arm systems with VirtIO - let alone legacy VirtIO. If there are people that need this functionality they need to at least make themselves known. -- Alex Bennée Virtualisation Tech Lead @ Linaro
On Wed, Dec 17, 2025 at 05:13:04PM +0000, Alex Bennée wrote:
Daniel P. Berrangé <berrange@redhat.com> writes:
On Wed, Dec 17, 2025 at 03:06:57PM +0100, Philippe Mathieu-Daudé wrote:
We couldn't find a way (guest OS with VirtIO drivers) to test a legacy VirtIO device on a ARM vCPU running in big-endian.
Deprecate for the v11.0 release, giving 1 year to users who really care to contribute functional tests.
Suggested-by: Alex Bennée <alex.bennee@linaro.org> Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org> --- docs/about/deprecated.rst | 11 +++++++++++ 1 file changed, 11 insertions(+)
diff --git a/docs/about/deprecated.rst b/docs/about/deprecated.rst index ac31a2bce42..3a69facb0f1 100644 --- a/docs/about/deprecated.rst +++ b/docs/about/deprecated.rst @@ -515,6 +515,17 @@ It was implemented as a no-op instruction in TCG up to QEMU 9.0, but only with ``-cpu max`` (which does not guarantee migration compatibility across versions).
+VirtIO devices +'''''''''''''' + +Legacy VirtIO devices on Big-Endian ARM architecture (since 11.0) +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +There are no functional tests for legacy virtio devices used by ARM +machines running in big-endian order, which makes harder to maintain +the code path while the code base evolve.
Lack of test coverage is not a reason to deprecate something.
We deprecate things we intend to intentionally remove or intentionally change in an incompatible manner.
We also deprecate things that stop us moving the code forward. c.f. the long process to deprecate 32 bit hosts.
IIUC we're intending to actively block the ability to build on 32 bit hosts. IOW, that's still an example of a deprecation where we will intentionally remove some functionality, rather than just an untested usage scenario.
If something is not tested, that merely means it has lesser quality guarantees, and is liable to unintenionally get broken at times.
If we're planning to *intentionally* remove the ability to use legacy virtio on big endian, that would be a reason to deprecate. If so the deprecation message should say this, not talk about missing functional testing.
As far as I'm aware BE Arm is a very small niche and I'm not even sure anyone runs BE Arm systems with VirtIO - let alone legacy VirtIO. If there are people that need this functionality they need to at least make themselves known.
Is there some technical change we're intending to make that will intentionally impact virtio legacy on BE ? ie, if we add the deprecation, then 2 releases later, what is the code change that means we move it from deprecated.rst into removed-features.rst ? With regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
participants (4)
-
Alex Bennée -
Daniel P. Berrangé -
Manos Pitsidianakis -
Philippe Mathieu-Daudé