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.
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.
Regards,
BALATON Zoltan
