On Wed, 18 Feb 2026, Pierrick Bouvier wrote:
On 2/18/26 3:46 PM, BALATON Zoltan wrote:
On Wed, 18 Feb 2026, Pierrick Bouvier wrote:
On 2/18/26 2:28 PM, BALATON Zoltan wrote:
On Wed, 18 Feb 2026, Pierrick Bouvier wrote:
On 2/18/26 2:17 PM, Pierrick Bouvier wrote:
On 2/18/26 1:00 PM, Philippe Mathieu-Daudé wrote:
On 13/2/26 00:46, Pierrick Bouvier wrote:
This simplifies code compared to having
virtio_vdev_has_feature(vdev, VIRTIO_F_VERSION_1) or
!virtio_vdev_has_feature(vdev, VIRTIO_F_VERSION_1).
Signed-off-by: Pierrick Bouvier <[email protected]>
---
include/hw/virtio/virtio-access.h | 3 +--
include/hw/virtio/virtio.h | 12 +++++++++++-
hw/net/virtio-net.c | 2 +-
hw/virtio/vhost.c | 2 +-
hw/virtio/virtio-pci.c | 2 +-
hw/virtio/virtio.c | 16 ++++++++--------
6 files changed, 23 insertions(+), 14 deletions(-)
diff --git a/include/hw/virtio/virtio.h b/include/hw/virtio/virtio.h
index 27cd98d2fe1..8f1e4323599 100644
--- a/include/hw/virtio/virtio.h
+++ b/include/hw/virtio/virtio.h
@@ -468,9 +468,19 @@ static inline bool
virtio_host_has_feature(VirtIODevice *vdev,
return virtio_has_feature(vdev->host_features, fbit);
}
+static inline bool virtio_vdev_is_modern(const VirtIODevice
*vdev)
+{
+ return virtio_vdev_has_feature(vdev, VIRTIO_F_VERSION_1);
+}
+
+static inline bool virtio_vdev_is_legacy(const VirtIODevice *vdev)
+{
+ return !virtio_vdev_is_modern(vdev);
+}
With retrospective, mentioning 'modern' was a mistake IMHO. But I
understand it was simpler to add 'modern' code without updating the
'legacy' code base. Today I'd rather have 'legacy' explicit in
function
names, everything else being the normal / current / modern version,
without having to clarify it.
Agree.
Thus back to this series I'd rather not introduce
virtio_vdev_is_modern
and use !virtio_vdev_is_legacy instead.
Sounds good. I feel it's still easier and clearer to read than
"!has_feature(1.0)". But as said in my previous answer to Zoltan, I
don't mind this patch too much, only 3rd one really matter.
s/!has_feature(1.0)/has_feature(1.0), thus showing I've been confused
once
more :).
The has_feature(1.0) is more specific though. What if 1.0 becomes legacy
too? Then modern and legacy is more confusing than testing for a specific
feature. I still think not touching this would be the easiest as the
introduced legacy/modern does not seem to make it much clearer.
As you can find in official Virtio spec, "legacy" is not a random name or
something I personally chose, it's the official term for pre 1.0
devices/interfaces.
https://docs.oasis-open.org/virtio/virtio/v1.4/virtio-v1.4.html#x1-60001
```
1.3.1 Legacy Interface: Terminology
Legacy Interface
is an interface specified by an earlier draft of this specification
(before
1.0)
Legacy Device
is a device implemented before this specification was released, and
implementing a legacy interface on the host side
```
So even if VirtIO 2.0 comes out one day, they will have to define or
change
term accordingly.
OK in that case it's better but modern would still be ambiguous. But as I
said I think current test for feature is OK in my opinion. That's all I
can add to this.
Your comments are welcome also on patch 3 by the way.
Sorry I can't comment on that as I don't know this code. I also don't use
virtio with PPC machines but I know some people use it so they'll probably
complain if this broke something.
I did my fair share of tests, including reproducing a ppc64el environment to
make sure migration was not broken. I hope someone comfortable with this can
give a reviewed-by and that Michael will happily pick the patch.
But maybe everybody uses current virtio now and the old one is only there
for compatibility. Is this maybe referenced from hw/core/machine.c in a
compatibility property that could be removed or is it user settable and
still supported? There was another thread on these compatibility
properties and adding a way to mark and deprecate compatibility properties
for easier removal but that did not end yet. You'd probably just want to
make this series do the least changes needed and then move on.
Philippe went down this way, trying to remove legacy support completely, but
the community answered it had to stay and could not be deprecated/removed.
This position might change in the future, but we need to find a solution now
to remove target specifics, thus the current solution.
I don't know if that's related but in hw/core/machine.c:
GlobalProperty hw_compat_5_0[] = {
...
{ "virtio-device", "x-disable-legacy-check", "true" },
};
And the oldest visible machine is now 5.1 with everything older than 8.0
deprecated due to auto deprecation. But we're behind with removing older
code which is now at 2.8 so maybe we're deprecating things faster than we
can remove and clean up old code so that may cause users problems before
the code can benefit from it. Maybe we could slow down with auto
deprecation until removal of old machine is catching up?
Regards,
BALATON Zoltan
