On Wed, Dec 17, 2025 at 05:13:04PM +0000, Alex Bennée wrote: > Daniel P. Berrangé <[email protected]> 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 <[email protected]> > >> Signed-off-by: Philippe Mathieu-Daudé <[email protected]> > >> --- > >> 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 :|
