qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Akihiko Odaki <akihiko.odaki@daynix.com>
To: "Michael S. Tsirkin" <mst@redhat.com>,
	Marcel Apfelbaum <marcel.apfelbaum@gmail.com>,
	Washizu Yui <yui.washidu@gmail.com>,
	"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>
Subject: [RFC] Flexible SR-IOV support for virtio-net
Date: Sat, 18 Nov 2023 21:10:33 +0900	[thread overview]
Message-ID: <5d46f455-f530-4e5e-9ae7-13a2297d4bc5@daynix.com> (raw)

Hi,

We are planning to add PCIe SR-IOV support to the virtio-net driver for 
Windows ("NetKVM")[1], and we want a SR-IOV feature for virtio-net 
emulation code in QEMU to test it. I expect there are other people 
interested in such a feature, considering that people are using igb[2] 
to test SR-IOV support in VMs.

Washizu Yui have already proposed an RFC patch to add a SR-IOV feature 
to virtio-net emulation[3][4] but it's preliminary and has no 
configurability for VFs.

Now I'm proposing to add SR-IOV support to virtio-net with full 
configurability for VFs by following the implementation of virtio-net 
failover[5]. I'm planning to write patches myself, but I know there are 
people interested in such patches so I'd like to let you know the idea 
beforehand.

The idea:

The problem when implementing configurability for VFs is that SR-IOV VFs 
can be realized and unrealized at runtime with a request from the guest. 
So a naive implementation cannot deal with a command line like the 
following:
-device virtio-net-pci,addr=0x0.0x0,sriov=on
-device virtio-net-pci,addr=0x0.0x1
-device virtio-net-pci,addr=0x0.0x2

This will realize the virtio-net functions in 0x0.0x1 and 0x0.0x2 when 
the guest starts instead of when the guest requests to enable VFs.

However, reviewing the virtio-net emulation code, I realized the 
virtio-net failover also "hides" devices when the guest starts. The 
following command line hides hostdev0 when the guest starts, and adds it 
when the guest requests VIRTIO_NET_F_STANDBY feature:

-device virtio-net-pci,netdev=hostnet1,id=net1,mac=52:54:00:6f:55:cc, \
   bus=root2,failover=on
-device vfiopci,host=5e:00.2,id=hostdev0,bus=root1,failover_pair_id=net1

So it should be also possible to do similar to "hide" VFs and 
realize/unrealize them when the guest requests.

There are two things I hate with this idea when contrasting it with the 
conventional multifunction feature[6] though. One is that the PF must be 
added before VFs; a similar limitation is imposed for failover.

Another is that it will be specific to virtio-net. I was considering to 
implement a "generic" SR-IOV feature that will work on various devices, 
but I realized that will need lots of configuration validations. We may 
eventually want it, but probably it's better to avoid such a big leap as 
the first step.

Please tell me if you have questions or suggestions.

Regards,
Akihiko Odaki

[1] https://github.com/virtio-win/kvm-guest-drivers-windows
[2] https://qemu.readthedocs.io/en/v8.1.0/system/devices/igb.html
[3] 
https://patchew.org/QEMU/1689731808-3009-1-git-send-email-yui.washidu@gmail.com/
[4] 
https://netdevconf.info/0x17/sessions/talk/unleashing-sr-iov-offload-on-virtual-machines.html
[5] https://qemu.readthedocs.io/en/v8.1.0/system/virtio-net-failover.html
[6] https://gitlab.com/qemu-project/qemu/-/blob/v8.1.2/docs/pcie.txt


             reply	other threads:[~2023-11-18 12:11 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-11-18 12:10 Akihiko Odaki [this message]
2023-11-28  8:47 ` [RFC] Flexible SR-IOV support for virtio-net Yui Washizu
2023-11-28  9:34   ` Akihiko Odaki

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=5d46f455-f530-4e5e-9ae7-13a2297d4bc5@daynix.com \
    --to=akihiko.odaki@daynix.com \
    --cc=marcel.apfelbaum@gmail.com \
    --cc=mst@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=yui.washidu@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).