hw/net/vhost_net-stub.c | 8 +- hw/net/vhost_net.c | 45 ++-- hw/net/virtio-net.c | 215 ++++++++++++------ hw/virtio/vhost-backend.c | 62 ++++- hw/virtio/vhost.c | 68 ++++-- hw/virtio/virtio-bus.c | 11 +- hw/virtio/virtio-hmp-cmds.c | 3 +- hw/virtio/virtio-pci.c | 74 +++++- hw/virtio/virtio-qmp.c | 91 +++++--- hw/virtio/virtio-qmp.h | 3 +- hw/virtio/virtio.c | 100 +++++--- include/hw/virtio/vhost-backend.h | 6 + include/hw/virtio/vhost.h | 56 ++++- include/hw/virtio/virtio-features.h | 127 +++++++++++ include/hw/virtio/virtio-net.h | 2 +- include/hw/virtio/virtio-pci.h | 2 +- include/hw/virtio/virtio.h | 11 +- include/net/net.h | 5 + include/net/vhost_net.h | 33 ++- include/standard-headers/drm/drm_fourcc.h | 56 ++++- include/standard-headers/linux/ethtool.h | 4 +- .../linux/input-event-codes.h | 8 + include/standard-headers/linux/input.h | 1 + include/standard-headers/linux/pci_regs.h | 9 + include/standard-headers/linux/vhost_types.h | 5 + include/standard-headers/linux/virtio_net.h | 33 +++ linux-headers/LICENSES/preferred/GPL-2.0 | 10 +- linux-headers/asm-arm64/unistd_64.h | 2 + linux-headers/asm-generic/unistd.h | 8 +- linux-headers/asm-loongarch/unistd_64.h | 2 + linux-headers/asm-mips/unistd_n32.h | 2 + linux-headers/asm-mips/unistd_n64.h | 2 + linux-headers/asm-mips/unistd_o32.h | 2 + linux-headers/asm-powerpc/kvm.h | 13 -- linux-headers/asm-powerpc/unistd_32.h | 2 + linux-headers/asm-powerpc/unistd_64.h | 2 + linux-headers/asm-riscv/kvm.h | 1 + linux-headers/asm-riscv/unistd_32.h | 2 + linux-headers/asm-riscv/unistd_64.h | 2 + linux-headers/asm-s390/unistd_32.h | 2 + linux-headers/asm-s390/unistd_64.h | 2 + linux-headers/asm-x86/unistd_32.h | 2 + linux-headers/asm-x86/unistd_64.h | 2 + linux-headers/asm-x86/unistd_x32.h | 2 + linux-headers/linux/iommufd.h | 154 ++++++++++++- linux-headers/linux/kvm.h | 2 + linux-headers/linux/vfio.h | 12 +- linux-headers/linux/vhost.h | 35 +++ net/net.c | 12 +- net/tap-bsd.c | 5 + net/tap-linux.c | 17 ++ net/tap-linux.h | 9 + net/tap-solaris.c | 5 + net/tap-stub.c | 5 + net/tap.c | 13 ++ net/tap_int.h | 1 + qapi/virtio.json | 9 +- scripts/update-linux-headers.sh | 1 + 58 files changed, 1136 insertions(+), 242 deletions(-) create mode 100644 include/hw/virtio/virtio-features.h
Some virtualized deployments use UDP tunnel pervasively and are impacted
negatively by the lack of GSO support for such kind of traffic in the
virtual NIC driver.
The virtio_net specification recently introduced support for GSO over
UDP tunnel, and the kernel side of the implementation has been merged
into the net-next tree; this series updates the virtio implementation to
support such a feature.
Currently the qemu virtio support limits the feature space to 64 bits,
while the virtio specification allows for a larger number of features.
Specifically the GSO-over-UDP-tunnel-related virtio features use bits
65-69; the larger part of this series (patches 4-12) actually deals with
extending the features space.
The extended features are carried by fixed size uint64_t arrays,
bringing the current maximum features number to 128.
The patches use some syntactic sugar to try to minimize the otherwise
very large code churn. Specifically the extended features are boundled
in an union with 'legacy' features definition, allowing no changes in
the virtio devices not needing the extended features set.
The actual offload implementation is in patches 13 and 14 and boils down
to propagating the new offload to the tun devices and the vhost backend.
Patch 1 is a small pre-req refactor that ideally could enter the
tree separately; it's presented here in the same series to help
reviewers more easily getting the full picture, patch 2 updates to
linux headers update script to deal with annotations recently introduce
in the kernel and patch 3 is a needed linux headers update.
Tested with basic stream transfer with all the possible permutations of
host kernel/qemu/guest kernel with/without GSO over UDP tunnel support,
vs snapshots creation and restore and vs migration.
The new features are disabled by default to avoid compatibilty issues.
They could be enabled after that hw_compat_10_1 will be added, together
with the related compatiblity entries.
Based-on: 9d71108d7de139dd4f4e6efe6837cabb32bf5616.1755078918.git.pabeni@redhat.com
---
v4 -> v5:
- more sparse cleanup
- dropped RFC tag
- disable the new features by default
v4: https://lists.gnu.org/archive/html/qemu-devel/2025-07/msg05513.html
v3 -> v4:
- more sparse cleanups
- fix build failures on a couple of targets
v3: https://lists.gnu.org/archive/html/qemu-devel/2025-07/msg04872.html
v2 -> v3:
- consolidated suffixes for new fields to '_ex'
- avoid pre/post load trickery and relay on reset zeroing the features
- cleaned-up virtio store implementation deduplicating a bit of code
- many more cleanups, see the individual patches changelog for the
details
- I left patch 1 unmodified, still some hope we could live with that;)
v2: https://lists.gnu.org/archive/html/qemu-devel/2025-07/msg03000.html
Paolo Abeni (13):
linux-headers: deal with counted_by annotation
linux-headers: Update to Linux v6.17-rc1
virtio: introduce extended features type
virtio: serialize extended features state
virtio: add support for negotiating extended features
virtio-pci: implement support for extended features
vhost: add support for negotiating extended features
qmp: update virtio features map to support extended features
vhost-backend: implement extended features support
vhost-net: implement extended features support
virtio-net: implement extended features support
net: implement tunnel probing
net: implement UDP tunnel features offloading
hw/net/vhost_net-stub.c | 8 +-
hw/net/vhost_net.c | 45 ++--
hw/net/virtio-net.c | 215 ++++++++++++------
hw/virtio/vhost-backend.c | 62 ++++-
hw/virtio/vhost.c | 68 ++++--
hw/virtio/virtio-bus.c | 11 +-
hw/virtio/virtio-hmp-cmds.c | 3 +-
hw/virtio/virtio-pci.c | 74 +++++-
hw/virtio/virtio-qmp.c | 91 +++++---
hw/virtio/virtio-qmp.h | 3 +-
hw/virtio/virtio.c | 100 +++++---
include/hw/virtio/vhost-backend.h | 6 +
include/hw/virtio/vhost.h | 56 ++++-
include/hw/virtio/virtio-features.h | 127 +++++++++++
include/hw/virtio/virtio-net.h | 2 +-
include/hw/virtio/virtio-pci.h | 2 +-
include/hw/virtio/virtio.h | 11 +-
include/net/net.h | 5 +
include/net/vhost_net.h | 33 ++-
include/standard-headers/drm/drm_fourcc.h | 56 ++++-
include/standard-headers/linux/ethtool.h | 4 +-
.../linux/input-event-codes.h | 8 +
include/standard-headers/linux/input.h | 1 +
include/standard-headers/linux/pci_regs.h | 9 +
include/standard-headers/linux/vhost_types.h | 5 +
include/standard-headers/linux/virtio_net.h | 33 +++
linux-headers/LICENSES/preferred/GPL-2.0 | 10 +-
linux-headers/asm-arm64/unistd_64.h | 2 +
linux-headers/asm-generic/unistd.h | 8 +-
linux-headers/asm-loongarch/unistd_64.h | 2 +
linux-headers/asm-mips/unistd_n32.h | 2 +
linux-headers/asm-mips/unistd_n64.h | 2 +
linux-headers/asm-mips/unistd_o32.h | 2 +
linux-headers/asm-powerpc/kvm.h | 13 --
linux-headers/asm-powerpc/unistd_32.h | 2 +
linux-headers/asm-powerpc/unistd_64.h | 2 +
linux-headers/asm-riscv/kvm.h | 1 +
linux-headers/asm-riscv/unistd_32.h | 2 +
linux-headers/asm-riscv/unistd_64.h | 2 +
linux-headers/asm-s390/unistd_32.h | 2 +
linux-headers/asm-s390/unistd_64.h | 2 +
linux-headers/asm-x86/unistd_32.h | 2 +
linux-headers/asm-x86/unistd_64.h | 2 +
linux-headers/asm-x86/unistd_x32.h | 2 +
linux-headers/linux/iommufd.h | 154 ++++++++++++-
linux-headers/linux/kvm.h | 2 +
linux-headers/linux/vfio.h | 12 +-
linux-headers/linux/vhost.h | 35 +++
net/net.c | 12 +-
net/tap-bsd.c | 5 +
net/tap-linux.c | 17 ++
net/tap-linux.h | 9 +
net/tap-solaris.c | 5 +
net/tap-stub.c | 5 +
net/tap.c | 13 ++
net/tap_int.h | 1 +
qapi/virtio.json | 9 +-
scripts/update-linux-headers.sh | 1 +
58 files changed, 1136 insertions(+), 242 deletions(-)
create mode 100644 include/hw/virtio/virtio-features.h
--
2.50.1
On Wed, Aug 13, 2025 at 12:28:13PM +0200, Paolo Abeni wrote: >Some virtualized deployments use UDP tunnel pervasively and are impacted >negatively by the lack of GSO support for such kind of traffic in the >virtual NIC driver. > >The virtio_net specification recently introduced support for GSO over >UDP tunnel, and the kernel side of the implementation has been merged >into the net-next tree; this series updates the virtio implementation to >support such a feature. > >Currently the qemu virtio support limits the feature space to 64 bits, >while the virtio specification allows for a larger number of features. >Specifically the GSO-over-UDP-tunnel-related virtio features use bits >65-69; the larger part of this series (patches 4-12) actually deals with >extending the features space. > >The extended features are carried by fixed size uint64_t arrays, >bringing the current maximum features number to 128. > >The patches use some syntactic sugar to try to minimize the otherwise >very large code churn. Specifically the extended features are boundled >in an union with 'legacy' features definition, allowing no changes in >the virtio devices not needing the extended features set. > >The actual offload implementation is in patches 13 and 14 and boils down >to propagating the new offload to the tun devices and the vhost backend. > >Patch 1 is a small pre-req refactor that ideally could enter the >tree separately; it's presented here in the same series to help >reviewers more easily getting the full picture, patch 2 updates to >linux headers update script to deal with annotations recently introduce >in the kernel and patch 3 is a needed linux headers update. > >Tested with basic stream transfer with all the possible permutations of >host kernel/qemu/guest kernel with/without GSO over UDP tunnel support, >vs snapshots creation and restore and vs migration. > >The new features are disabled by default to avoid compatibilty issues. >They could be enabled after that hw_compat_10_1 will be added, together >with the related compatiblity entries. Okay, this should avoid any migration issue for now, but IIUC you will enable it in a followup patch, right? So for this series: Acked-by: Stefano Garzarella <sgarzare@redhat.com> Thanks, Stefano > >Based-on: 9d71108d7de139dd4f4e6efe6837cabb32bf5616.1755078918.git.pabeni@redhat.com >--- >v4 -> v5: > - more sparse cleanup > - dropped RFC tag > - disable the new features by default > >v4: https://lists.gnu.org/archive/html/qemu-devel/2025-07/msg05513.html > >v3 -> v4: > - more sparse cleanups > - fix build failures on a couple of targets >v3: https://lists.gnu.org/archive/html/qemu-devel/2025-07/msg04872.html > >v2 -> v3: > - consolidated suffixes for new fields to '_ex' > - avoid pre/post load trickery and relay on reset zeroing the features > - cleaned-up virtio store implementation deduplicating a bit of code > - many more cleanups, see the individual patches changelog for the > details > - I left patch 1 unmodified, still some hope we could live with that;) >v2: https://lists.gnu.org/archive/html/qemu-devel/2025-07/msg03000.html > >Paolo Abeni (13): > linux-headers: deal with counted_by annotation > linux-headers: Update to Linux v6.17-rc1 > virtio: introduce extended features type > virtio: serialize extended features state > virtio: add support for negotiating extended features > virtio-pci: implement support for extended features > vhost: add support for negotiating extended features > qmp: update virtio features map to support extended features > vhost-backend: implement extended features support > vhost-net: implement extended features support > virtio-net: implement extended features support > net: implement tunnel probing > net: implement UDP tunnel features offloading > > hw/net/vhost_net-stub.c | 8 +- > hw/net/vhost_net.c | 45 ++-- > hw/net/virtio-net.c | 215 ++++++++++++------ > hw/virtio/vhost-backend.c | 62 ++++- > hw/virtio/vhost.c | 68 ++++-- > hw/virtio/virtio-bus.c | 11 +- > hw/virtio/virtio-hmp-cmds.c | 3 +- > hw/virtio/virtio-pci.c | 74 +++++- > hw/virtio/virtio-qmp.c | 91 +++++--- > hw/virtio/virtio-qmp.h | 3 +- > hw/virtio/virtio.c | 100 +++++--- > include/hw/virtio/vhost-backend.h | 6 + > include/hw/virtio/vhost.h | 56 ++++- > include/hw/virtio/virtio-features.h | 127 +++++++++++ > include/hw/virtio/virtio-net.h | 2 +- > include/hw/virtio/virtio-pci.h | 2 +- > include/hw/virtio/virtio.h | 11 +- > include/net/net.h | 5 + > include/net/vhost_net.h | 33 ++- > include/standard-headers/drm/drm_fourcc.h | 56 ++++- > include/standard-headers/linux/ethtool.h | 4 +- > .../linux/input-event-codes.h | 8 + > include/standard-headers/linux/input.h | 1 + > include/standard-headers/linux/pci_regs.h | 9 + > include/standard-headers/linux/vhost_types.h | 5 + > include/standard-headers/linux/virtio_net.h | 33 +++ > linux-headers/LICENSES/preferred/GPL-2.0 | 10 +- > linux-headers/asm-arm64/unistd_64.h | 2 + > linux-headers/asm-generic/unistd.h | 8 +- > linux-headers/asm-loongarch/unistd_64.h | 2 + > linux-headers/asm-mips/unistd_n32.h | 2 + > linux-headers/asm-mips/unistd_n64.h | 2 + > linux-headers/asm-mips/unistd_o32.h | 2 + > linux-headers/asm-powerpc/kvm.h | 13 -- > linux-headers/asm-powerpc/unistd_32.h | 2 + > linux-headers/asm-powerpc/unistd_64.h | 2 + > linux-headers/asm-riscv/kvm.h | 1 + > linux-headers/asm-riscv/unistd_32.h | 2 + > linux-headers/asm-riscv/unistd_64.h | 2 + > linux-headers/asm-s390/unistd_32.h | 2 + > linux-headers/asm-s390/unistd_64.h | 2 + > linux-headers/asm-x86/unistd_32.h | 2 + > linux-headers/asm-x86/unistd_64.h | 2 + > linux-headers/asm-x86/unistd_x32.h | 2 + > linux-headers/linux/iommufd.h | 154 ++++++++++++- > linux-headers/linux/kvm.h | 2 + > linux-headers/linux/vfio.h | 12 +- > linux-headers/linux/vhost.h | 35 +++ > net/net.c | 12 +- > net/tap-bsd.c | 5 + > net/tap-linux.c | 17 ++ > net/tap-linux.h | 9 + > net/tap-solaris.c | 5 + > net/tap-stub.c | 5 + > net/tap.c | 13 ++ > net/tap_int.h | 1 + > qapi/virtio.json | 9 +- > scripts/update-linux-headers.sh | 1 + > 58 files changed, 1136 insertions(+), 242 deletions(-) > create mode 100644 include/hw/virtio/virtio-features.h > >-- >2.50.1 >
On 2025/08/13 19:28, Paolo Abeni wrote: > Some virtualized deployments use UDP tunnel pervasively and are impacted > negatively by the lack of GSO support for such kind of traffic in the > virtual NIC driver. > > The virtio_net specification recently introduced support for GSO over > UDP tunnel, and the kernel side of the implementation has been merged > into the net-next tree; this series updates the virtio implementation to > support such a feature. > > Currently the qemu virtio support limits the feature space to 64 bits, > while the virtio specification allows for a larger number of features. > Specifically the GSO-over-UDP-tunnel-related virtio features use bits > 65-69; the larger part of this series (patches 4-12) actually deals with > extending the features space. > > The extended features are carried by fixed size uint64_t arrays, > bringing the current maximum features number to 128. > > The patches use some syntactic sugar to try to minimize the otherwise > very large code churn. Specifically the extended features are boundled > in an union with 'legacy' features definition, allowing no changes in > the virtio devices not needing the extended features set. > > The actual offload implementation is in patches 13 and 14 and boils down > to propagating the new offload to the tun devices and the vhost backend. > > Patch 1 is a small pre-req refactor that ideally could enter the > tree separately; it's presented here in the same series to help > reviewers more easily getting the full picture, patch 2 updates to > linux headers update script to deal with annotations recently introduce > in the kernel and patch 3 is a needed linux headers update. > > Tested with basic stream transfer with all the possible permutations of > host kernel/qemu/guest kernel with/without GSO over UDP tunnel support, > vs snapshots creation and restore and vs migration. > > The new features are disabled by default to avoid compatibilty issues. > They could be enabled after that hw_compat_10_1 will be added, together > with the related compatiblity entries. > > Based-on: 9d71108d7de139dd4f4e6efe6837cabb32bf5616.1755078918.git.pabeni@redhat.com Now everything looks good to me. For the whole series: Reviewed-by: Akihiko Odaki <odaki@rsg.ci.i.u-tokyo.ac.jp> Regards, Akihiko Odaki
On Thu, Aug 28, 2025 at 9:47 AM Akihiko Odaki <odaki@rsg.ci.i.u-tokyo.ac.jp> wrote: > > On 2025/08/13 19:28, Paolo Abeni wrote: > > Some virtualized deployments use UDP tunnel pervasively and are impacted > > negatively by the lack of GSO support for such kind of traffic in the > > virtual NIC driver. > > > > The virtio_net specification recently introduced support for GSO over > > UDP tunnel, and the kernel side of the implementation has been merged > > into the net-next tree; this series updates the virtio implementation to > > support such a feature. > > > > Currently the qemu virtio support limits the feature space to 64 bits, > > while the virtio specification allows for a larger number of features. > > Specifically the GSO-over-UDP-tunnel-related virtio features use bits > > 65-69; the larger part of this series (patches 4-12) actually deals with > > extending the features space. > > > > The extended features are carried by fixed size uint64_t arrays, > > bringing the current maximum features number to 128. > > > > The patches use some syntactic sugar to try to minimize the otherwise > > very large code churn. Specifically the extended features are boundled > > in an union with 'legacy' features definition, allowing no changes in > > the virtio devices not needing the extended features set. > > > > The actual offload implementation is in patches 13 and 14 and boils down > > to propagating the new offload to the tun devices and the vhost backend. > > > > Patch 1 is a small pre-req refactor that ideally could enter the > > tree separately; it's presented here in the same series to help > > reviewers more easily getting the full picture, patch 2 updates to > > linux headers update script to deal with annotations recently introduce > > in the kernel and patch 3 is a needed linux headers update. > > > > Tested with basic stream transfer with all the possible permutations of > > host kernel/qemu/guest kernel with/without GSO over UDP tunnel support, > > vs snapshots creation and restore and vs migration. > > > > The new features are disabled by default to avoid compatibilty issues. > > They could be enabled after that hw_compat_10_1 will be added, together > > with the related compatiblity entries. > > > > Based-on: 9d71108d7de139dd4f4e6efe6837cabb32bf5616.1755078918.git.pabeni@redhat.com > > Now everything looks good to me. For the whole series: > > Reviewed-by: Akihiko Odaki <odaki@rsg.ci.i.u-tokyo.ac.jp> > > Regards, > Akihiko Odaki > Acked-by: Jason Wang <jasowang@redhat.com> Thanks
On 9/1/25 4:47 AM, Jason Wang wrote: > On Thu, Aug 28, 2025 at 9:47 AM Akihiko Odaki > <odaki@rsg.ci.i.u-tokyo.ac.jp> wrote: >> >> On 2025/08/13 19:28, Paolo Abeni wrote: >>> Some virtualized deployments use UDP tunnel pervasively and are impacted >>> negatively by the lack of GSO support for such kind of traffic in the >>> virtual NIC driver. >>> >>> The virtio_net specification recently introduced support for GSO over >>> UDP tunnel, and the kernel side of the implementation has been merged >>> into the net-next tree; this series updates the virtio implementation to >>> support such a feature. >>> >>> Currently the qemu virtio support limits the feature space to 64 bits, >>> while the virtio specification allows for a larger number of features. >>> Specifically the GSO-over-UDP-tunnel-related virtio features use bits >>> 65-69; the larger part of this series (patches 4-12) actually deals with >>> extending the features space. >>> >>> The extended features are carried by fixed size uint64_t arrays, >>> bringing the current maximum features number to 128. >>> >>> The patches use some syntactic sugar to try to minimize the otherwise >>> very large code churn. Specifically the extended features are boundled >>> in an union with 'legacy' features definition, allowing no changes in >>> the virtio devices not needing the extended features set. >>> >>> The actual offload implementation is in patches 13 and 14 and boils down >>> to propagating the new offload to the tun devices and the vhost backend. >>> >>> Patch 1 is a small pre-req refactor that ideally could enter the >>> tree separately; it's presented here in the same series to help >>> reviewers more easily getting the full picture, patch 2 updates to >>> linux headers update script to deal with annotations recently introduce >>> in the kernel and patch 3 is a needed linux headers update. >>> >>> Tested with basic stream transfer with all the possible permutations of >>> host kernel/qemu/guest kernel with/without GSO over UDP tunnel support, >>> vs snapshots creation and restore and vs migration. >>> >>> The new features are disabled by default to avoid compatibilty issues. >>> They could be enabled after that hw_compat_10_1 will be added, together >>> with the related compatiblity entries. >>> >>> Based-on: 9d71108d7de139dd4f4e6efe6837cabb32bf5616.1755078918.git.pabeni@redhat.com >> >> Now everything looks good to me. For the whole series: >> >> Reviewed-by: Akihiko Odaki <odaki@rsg.ci.i.u-tokyo.ac.jp> >> >> Regards, >> Akihiko Odaki >> > > Acked-by: Jason Wang <jasowang@redhat.com> Thank you for the feedback. I guess this series will go through Micheal's tree, am I correct? Also I suspect/fear it could need rebasing due to some other patches being applied meanwhile, please LMK if a repost is needed, thanks! Paolo
On Mon, Sep 01, 2025 at 08:44:46AM +0200, Paolo Abeni wrote: > On 9/1/25 4:47 AM, Jason Wang wrote: > > On Thu, Aug 28, 2025 at 9:47 AM Akihiko Odaki > > <odaki@rsg.ci.i.u-tokyo.ac.jp> wrote: > >> > >> On 2025/08/13 19:28, Paolo Abeni wrote: > >>> Some virtualized deployments use UDP tunnel pervasively and are impacted > >>> negatively by the lack of GSO support for such kind of traffic in the > >>> virtual NIC driver. > >>> > >>> The virtio_net specification recently introduced support for GSO over > >>> UDP tunnel, and the kernel side of the implementation has been merged > >>> into the net-next tree; this series updates the virtio implementation to > >>> support such a feature. > >>> > >>> Currently the qemu virtio support limits the feature space to 64 bits, > >>> while the virtio specification allows for a larger number of features. > >>> Specifically the GSO-over-UDP-tunnel-related virtio features use bits > >>> 65-69; the larger part of this series (patches 4-12) actually deals with > >>> extending the features space. > >>> > >>> The extended features are carried by fixed size uint64_t arrays, > >>> bringing the current maximum features number to 128. > >>> > >>> The patches use some syntactic sugar to try to minimize the otherwise > >>> very large code churn. Specifically the extended features are boundled > >>> in an union with 'legacy' features definition, allowing no changes in > >>> the virtio devices not needing the extended features set. > >>> > >>> The actual offload implementation is in patches 13 and 14 and boils down > >>> to propagating the new offload to the tun devices and the vhost backend. > >>> > >>> Patch 1 is a small pre-req refactor that ideally could enter the > >>> tree separately; it's presented here in the same series to help > >>> reviewers more easily getting the full picture, patch 2 updates to > >>> linux headers update script to deal with annotations recently introduce > >>> in the kernel and patch 3 is a needed linux headers update. > >>> > >>> Tested with basic stream transfer with all the possible permutations of > >>> host kernel/qemu/guest kernel with/without GSO over UDP tunnel support, > >>> vs snapshots creation and restore and vs migration. > >>> > >>> The new features are disabled by default to avoid compatibilty issues. > >>> They could be enabled after that hw_compat_10_1 will be added, together > >>> with the related compatiblity entries. > >>> > >>> Based-on: 9d71108d7de139dd4f4e6efe6837cabb32bf5616.1755078918.git.pabeni@redhat.com > >> > >> Now everything looks good to me. For the whole series: > >> > >> Reviewed-by: Akihiko Odaki <odaki@rsg.ci.i.u-tokyo.ac.jp> > >> > >> Regards, > >> Akihiko Odaki > >> > > > > Acked-by: Jason Wang <jasowang@redhat.com> > > Thank you for the feedback. I guess this series will go through > Micheal's tree, am I correct? > > Also I suspect/fear it could need rebasing due to some other patches > being applied meanwhile, please LMK if a repost is needed, thanks! > > Paolo Yes - I am however traveling for the KVM forum. Will work on it when I am back.
On Mon, Sep 1, 2025 at 2:44 PM Paolo Abeni <pabeni@redhat.com> wrote: > > On 9/1/25 4:47 AM, Jason Wang wrote: > > On Thu, Aug 28, 2025 at 9:47 AM Akihiko Odaki > > <odaki@rsg.ci.i.u-tokyo.ac.jp> wrote: > >> > >> On 2025/08/13 19:28, Paolo Abeni wrote: > >>> Some virtualized deployments use UDP tunnel pervasively and are impacted > >>> negatively by the lack of GSO support for such kind of traffic in the > >>> virtual NIC driver. > >>> > >>> The virtio_net specification recently introduced support for GSO over > >>> UDP tunnel, and the kernel side of the implementation has been merged > >>> into the net-next tree; this series updates the virtio implementation to > >>> support such a feature. > >>> > >>> Currently the qemu virtio support limits the feature space to 64 bits, > >>> while the virtio specification allows for a larger number of features. > >>> Specifically the GSO-over-UDP-tunnel-related virtio features use bits > >>> 65-69; the larger part of this series (patches 4-12) actually deals with > >>> extending the features space. > >>> > >>> The extended features are carried by fixed size uint64_t arrays, > >>> bringing the current maximum features number to 128. > >>> > >>> The patches use some syntactic sugar to try to minimize the otherwise > >>> very large code churn. Specifically the extended features are boundled > >>> in an union with 'legacy' features definition, allowing no changes in > >>> the virtio devices not needing the extended features set. > >>> > >>> The actual offload implementation is in patches 13 and 14 and boils down > >>> to propagating the new offload to the tun devices and the vhost backend. > >>> > >>> Patch 1 is a small pre-req refactor that ideally could enter the > >>> tree separately; it's presented here in the same series to help > >>> reviewers more easily getting the full picture, patch 2 updates to > >>> linux headers update script to deal with annotations recently introduce > >>> in the kernel and patch 3 is a needed linux headers update. > >>> > >>> Tested with basic stream transfer with all the possible permutations of > >>> host kernel/qemu/guest kernel with/without GSO over UDP tunnel support, > >>> vs snapshots creation and restore and vs migration. > >>> > >>> The new features are disabled by default to avoid compatibilty issues. > >>> They could be enabled after that hw_compat_10_1 will be added, together > >>> with the related compatiblity entries. > >>> > >>> Based-on: 9d71108d7de139dd4f4e6efe6837cabb32bf5616.1755078918.git.pabeni@redhat.com > >> > >> Now everything looks good to me. For the whole series: > >> > >> Reviewed-by: Akihiko Odaki <odaki@rsg.ci.i.u-tokyo.ac.jp> > >> > >> Regards, > >> Akihiko Odaki > >> > > > > Acked-by: Jason Wang <jasowang@redhat.com> > > Thank you for the feedback. I guess this series will go through > Micheal's tree, am I correct? Yes. I think so. > > Also I suspect/fear it could need rebasing due to some other patches > being applied meanwhile, please LMK if a repost is needed, thanks! > > Paolo > Thanks
Tested this series of patches with virtio-net regression cases, everything works fine. Tested-by: Lei Yang <leiyang@redhat.com> On Wed, Aug 13, 2025 at 6:30 PM Paolo Abeni <pabeni@redhat.com> wrote: > > Some virtualized deployments use UDP tunnel pervasively and are impacted > negatively by the lack of GSO support for such kind of traffic in the > virtual NIC driver. > > The virtio_net specification recently introduced support for GSO over > UDP tunnel, and the kernel side of the implementation has been merged > into the net-next tree; this series updates the virtio implementation to > support such a feature. > > Currently the qemu virtio support limits the feature space to 64 bits, > while the virtio specification allows for a larger number of features. > Specifically the GSO-over-UDP-tunnel-related virtio features use bits > 65-69; the larger part of this series (patches 4-12) actually deals with > extending the features space. > > The extended features are carried by fixed size uint64_t arrays, > bringing the current maximum features number to 128. > > The patches use some syntactic sugar to try to minimize the otherwise > very large code churn. Specifically the extended features are boundled > in an union with 'legacy' features definition, allowing no changes in > the virtio devices not needing the extended features set. > > The actual offload implementation is in patches 13 and 14 and boils down > to propagating the new offload to the tun devices and the vhost backend. > > Patch 1 is a small pre-req refactor that ideally could enter the > tree separately; it's presented here in the same series to help > reviewers more easily getting the full picture, patch 2 updates to > linux headers update script to deal with annotations recently introduce > in the kernel and patch 3 is a needed linux headers update. > > Tested with basic stream transfer with all the possible permutations of > host kernel/qemu/guest kernel with/without GSO over UDP tunnel support, > vs snapshots creation and restore and vs migration. > > The new features are disabled by default to avoid compatibilty issues. > They could be enabled after that hw_compat_10_1 will be added, together > with the related compatiblity entries. > > Based-on: 9d71108d7de139dd4f4e6efe6837cabb32bf5616.1755078918.git.pabeni@redhat.com > --- > v4 -> v5: > - more sparse cleanup > - dropped RFC tag > - disable the new features by default > > v4: https://lists.gnu.org/archive/html/qemu-devel/2025-07/msg05513.html > > v3 -> v4: > - more sparse cleanups > - fix build failures on a couple of targets > v3: https://lists.gnu.org/archive/html/qemu-devel/2025-07/msg04872.html > > v2 -> v3: > - consolidated suffixes for new fields to '_ex' > - avoid pre/post load trickery and relay on reset zeroing the features > - cleaned-up virtio store implementation deduplicating a bit of code > - many more cleanups, see the individual patches changelog for the > details > - I left patch 1 unmodified, still some hope we could live with that;) > v2: https://lists.gnu.org/archive/html/qemu-devel/2025-07/msg03000.html > > Paolo Abeni (13): > linux-headers: deal with counted_by annotation > linux-headers: Update to Linux v6.17-rc1 > virtio: introduce extended features type > virtio: serialize extended features state > virtio: add support for negotiating extended features > virtio-pci: implement support for extended features > vhost: add support for negotiating extended features > qmp: update virtio features map to support extended features > vhost-backend: implement extended features support > vhost-net: implement extended features support > virtio-net: implement extended features support > net: implement tunnel probing > net: implement UDP tunnel features offloading > > hw/net/vhost_net-stub.c | 8 +- > hw/net/vhost_net.c | 45 ++-- > hw/net/virtio-net.c | 215 ++++++++++++------ > hw/virtio/vhost-backend.c | 62 ++++- > hw/virtio/vhost.c | 68 ++++-- > hw/virtio/virtio-bus.c | 11 +- > hw/virtio/virtio-hmp-cmds.c | 3 +- > hw/virtio/virtio-pci.c | 74 +++++- > hw/virtio/virtio-qmp.c | 91 +++++--- > hw/virtio/virtio-qmp.h | 3 +- > hw/virtio/virtio.c | 100 +++++--- > include/hw/virtio/vhost-backend.h | 6 + > include/hw/virtio/vhost.h | 56 ++++- > include/hw/virtio/virtio-features.h | 127 +++++++++++ > include/hw/virtio/virtio-net.h | 2 +- > include/hw/virtio/virtio-pci.h | 2 +- > include/hw/virtio/virtio.h | 11 +- > include/net/net.h | 5 + > include/net/vhost_net.h | 33 ++- > include/standard-headers/drm/drm_fourcc.h | 56 ++++- > include/standard-headers/linux/ethtool.h | 4 +- > .../linux/input-event-codes.h | 8 + > include/standard-headers/linux/input.h | 1 + > include/standard-headers/linux/pci_regs.h | 9 + > include/standard-headers/linux/vhost_types.h | 5 + > include/standard-headers/linux/virtio_net.h | 33 +++ > linux-headers/LICENSES/preferred/GPL-2.0 | 10 +- > linux-headers/asm-arm64/unistd_64.h | 2 + > linux-headers/asm-generic/unistd.h | 8 +- > linux-headers/asm-loongarch/unistd_64.h | 2 + > linux-headers/asm-mips/unistd_n32.h | 2 + > linux-headers/asm-mips/unistd_n64.h | 2 + > linux-headers/asm-mips/unistd_o32.h | 2 + > linux-headers/asm-powerpc/kvm.h | 13 -- > linux-headers/asm-powerpc/unistd_32.h | 2 + > linux-headers/asm-powerpc/unistd_64.h | 2 + > linux-headers/asm-riscv/kvm.h | 1 + > linux-headers/asm-riscv/unistd_32.h | 2 + > linux-headers/asm-riscv/unistd_64.h | 2 + > linux-headers/asm-s390/unistd_32.h | 2 + > linux-headers/asm-s390/unistd_64.h | 2 + > linux-headers/asm-x86/unistd_32.h | 2 + > linux-headers/asm-x86/unistd_64.h | 2 + > linux-headers/asm-x86/unistd_x32.h | 2 + > linux-headers/linux/iommufd.h | 154 ++++++++++++- > linux-headers/linux/kvm.h | 2 + > linux-headers/linux/vfio.h | 12 +- > linux-headers/linux/vhost.h | 35 +++ > net/net.c | 12 +- > net/tap-bsd.c | 5 + > net/tap-linux.c | 17 ++ > net/tap-linux.h | 9 + > net/tap-solaris.c | 5 + > net/tap-stub.c | 5 + > net/tap.c | 13 ++ > net/tap_int.h | 1 + > qapi/virtio.json | 9 +- > scripts/update-linux-headers.sh | 1 + > 58 files changed, 1136 insertions(+), 242 deletions(-) > create mode 100644 include/hw/virtio/virtio-features.h > > -- > 2.50.1 > >
Hi Jason, On Wed, Aug 13, 2025 at 6:30 PM Paolo Abeni <pabeni@redhat.com> wrote: > Some virtualized deployments use UDP tunnel pervasively and are impacted > negatively by the lack of GSO support for such kind of traffic in the > virtual NIC driver. > > The virtio_net specification recently introduced support for GSO over > UDP tunnel, and the kernel side of the implementation has been merged > into the net-next tree; this series updates the virtio implementation to > support such a feature. > > Currently the qemu virtio support limits the feature space to 64 bits, > while the virtio specification allows for a larger number of features. > Specifically the GSO-over-UDP-tunnel-related virtio features use bits > 65-69; the larger part of this series (patches 4-12) actually deals with > extending the features space. > > The extended features are carried by fixed size uint64_t arrays, > bringing the current maximum features number to 128. > > The patches use some syntactic sugar to try to minimize the otherwise > very large code churn. Specifically the extended features are boundled > in an union with 'legacy' features definition, allowing no changes in > the virtio devices not needing the extended features set. > > The actual offload implementation is in patches 13 and 14 and boils down > to propagating the new offload to the tun devices and the vhost backend. > > Patch 1 is a small pre-req refactor that ideally could enter the > tree separately; it's presented here in the same series to help > reviewers more easily getting the full picture, patch 2 updates to > linux headers update script to deal with annotations recently introduce > in the kernel and patch 3 is a needed linux headers update. > > Tested with basic stream transfer with all the possible permutations of > host kernel/qemu/guest kernel with/without GSO over UDP tunnel support, > vs snapshots creation and restore and vs migration. > > The new features are disabled by default to avoid compatibilty issues. > They could be enabled after that hw_compat_10_1 will be added, together > with the related compatiblity entries. > > Based-on: 9d71108d7de139dd4f4e6efe6837cabb32bf5616.1755078918.git.pabeni@redhat.com I'm wondering you could have a look at this series and its pre-req: https://lists.gnu.org/archive/html/qemu-devel/2025-08/msg02004.html Thanks, Paolo
© 2016 - 2025 Red Hat, Inc.