Re: [PATCH] hw/arm: Deprecate legacy VirtIO devices on big-endian guests

["Daniel P. Berrangé" <berrange@redhat.com>]

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 :|