From: Yui Washizu <yui.washidu@gmail.com>
To: "Akihiko Odaki" <akihiko.odaki@daynix.com>,
"Michael S. Tsirkin" <mst@redhat.com>,
"Marcel Apfelbaum" <marcel.apfelbaum@gmail.com>,
"Alex Williamson" <alex.williamson@redhat.com>,
"Cédric Le Goater" <clg@redhat.com>,
"Paolo Bonzini" <pbonzini@redhat.com>,
"Daniel P. Berrangé" <berrange@redhat.com>,
"Eduardo Habkost" <eduardo@habkost.net>,
"Jason Wang" <jasowang@redhat.com>,
"Sriram Yagnaraman" <sriram.yagnaraman@est.tech>,
"Keith Busch" <kbusch@kernel.org>,
"Klaus Jensen" <its@irrelevant.dk>
Cc: qemu-devel@nongnu.org, qemu-block@nongnu.org
Subject: Re: [PATCH RFC v2 00/12] virtio-net: add support for SR-IOV emulation
Date: Tue, 19 Dec 2023 17:37:44 +0900 [thread overview]
Message-ID: <432f9b3b-2d91-4bc8-aca4-0ef3569a622e@gmail.com> (raw)
In-Reply-To: <20231210-sriov-v2-0-b959e8a6dfaf@daynix.com>
On 2023/12/10 13:05, Akihiko Odaki wrote:
> Introduction
> ------------
>
> This series is based on the RFC series submitted by Yui Washizu[1].
> See also [2] for the context.
>
> This series enables SR-IOV emulation for virtio-net. It is useful
> to test SR-IOV support on the guest, or to expose several vDPA devices
> in a VM. vDPA devices can also provide L2 switching feature for
> offloading though it is out of scope to allow the guest to configure
> such a feature.
>
> The PF side code resides in virtio-pci. The VF side code resides in
> the PCI common infrastructure, but it is restricted to work only for
> virtio-net-pci because of lack of validation.
>
> User Interface
> --------------
>
> A user can configure a SR-IOV capable virtio-net device by adding
> virtio-net-pci functions to a bus. Below is a command line example:
> -netdev user,id=n -netdev user,id=o
> -netdev user,id=p -netdev user,id=q
> -device pcie-root-port,id=b
> -device virtio-net-pci,bus=b,addr=0x0.0x3,netdev=q,sriov-pf=f
> -device virtio-net-pci,bus=b,addr=0x0.0x2,netdev=p,sriov-pf=f
> -device virtio-net-pci,bus=b,addr=0x0.0x1,netdev=o,sriov-pf=f
> -device virtio-net-pci,bus=b,addr=0x0.0x0,netdev=n,id=f
>
> The VFs specify the paired PF with "sriov-pf" property. The PF must be
> added after all VFs. It is user's responsibility to ensure that VFs have
> function numbers larger than one of the PF, and the function numbers
> have a consistent stride.
I attempted to create a VF on a VM using your patches and
tested the creation of one VF on the VM.
I initiated QEMU with the following commands:
-netdev tap,id=n,vhost=on -netdev tap,id=o,vhost=on
-device pcie-root-port,id=b
-device virtio-net-pci,bus=b,addr=0x0.0x1,netdev=o,sriov-pf=f
-device virtio-net-pci,bus=b,addr=0x0.0x0,netdev=n,id=f
However, when creating just one VF,
QEMU crashed at hw/pci/pci.c:1443.
---
uint32_t vf_num = (d->devfn - (pf->devfn + vf_offset)) / vf_stride;
---
The error output was:
'CPU 1/KVM trap divide error ip:... sp:... error:0 in kvm-qemu.'
Interestingly, when creating two VFs, QEMU did not crash.
>
> Keeping VF instances
> --------------------
>
> A problem with SR-IOV emulation is that it needs to hotplug the VFs as
> the guest requests. Previously, this behavior was implemented by
> realizing and unrealizing VFs at runtime. However, this strategy does
> not work well for the proposed virtio-net emulation; in this proposal,
> device options passed in the command line must be maintained as VFs
> are hotplugged, but they are consumed when the machine starts and not
> available after that, which makes realizing VFs at runtime impossible.
>
> As an strategy alternative to runtime realization/unrealization, this
> series proposes to reuse the code to power down PCI Express devices.
> When a PCI Express device is powered down, it will be hidden from the
> guest but will be kept realized. This effectively implements the
> behavior we need for the SR-IOV emulation.
>
> Summary
> -------
>
> Patch [1, 5] refactors the PCI infrastructure code.
> Patch [6, 10] adds user-created SR-IOV VF infrastructure.
> Patch 11 makes virtio-pci work as SR-IOV PF for user-created VFs.
> Patch 12 allows user to create SR-IOV VFs with virtio-net-pci.
>
> [1] https://patchew.org/QEMU/1689731808-3009-1-git-send-email-yui.washidu@gmail.com/
> [2] https://lore.kernel.org/all/5d46f455-f530-4e5e-9ae7-13a2297d4bc5@daynix.com/
>
> Co-developed-by: Yui Washizu <yui.washidu@gmail.com>
> Signed-off-by: Akihiko Odaki <akihiko.odaki@daynix.com>
> ---
> Changes in v2:
> - Changed to keep VF instances.
> - Link to v1: https://lore.kernel.org/r/20231202-sriov-v1-0-32b3570f7bd6@daynix.com
>
> ---
> Akihiko Odaki (12):
> hw/pci: Initialize PCI multifunction after realization
> hw/pci: Determine if rombar is explicitly enabled
> hw/pci: Do not add ROM BAR for SR-IOV VF
> vfio: Avoid inspecting option QDict for rombar
> hw/qdev: Remove opts member
> pcie_sriov: Reuse SR-IOV VF device instances
> pcie_sriov: Release VFs failed to realize
> pcie_sriov: Ensure PF and VF are mutually exclusive
> pcie_sriov: Check PCI Express for SR-IOV PF
> pcie_sriov: Allow user to create SR-IOV device
> virtio-pci: Implement SR-IOV PF
> virtio-net: Implement SR-IOV VF
>
> docs/pcie_sriov.txt | 8 +-
> include/hw/pci/pci.h | 2 +-
> include/hw/pci/pci_device.h | 13 +-
> include/hw/pci/pcie_sriov.h | 25 ++-
> include/hw/qdev-core.h | 4 -
> hw/core/qdev.c | 1 -
> hw/net/igb.c | 3 +-
> hw/nvme/ctrl.c | 3 +-
> hw/pci/pci.c | 98 +++++++-----
> hw/pci/pci_host.c | 4 +-
> hw/pci/pcie.c | 4 +-
> hw/pci/pcie_sriov.c | 360 +++++++++++++++++++++++++++++++++-----------
> hw/vfio/pci.c | 3 +-
> hw/virtio/virtio-net-pci.c | 1 +
> hw/virtio/virtio-pci.c | 7 +
> system/qdev-monitor.c | 12 +-
> 16 files changed, 395 insertions(+), 153 deletions(-)
> ---
> base-commit: 4705fc0c8511d073bee4751c3c974aab2b10a970
> change-id: 20231202-sriov-9402fb262be8
>
> Best regards,
prev parent reply other threads:[~2023-12-19 8:38 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-12-10 4:05 [PATCH RFC v2 00/12] virtio-net: add support for SR-IOV emulation Akihiko Odaki
2023-12-10 4:05 ` [PATCH RFC v2 01/12] hw/pci: Initialize PCI multifunction after realization Akihiko Odaki
2023-12-12 9:59 ` Philippe Mathieu-Daudé
2023-12-10 4:05 ` [PATCH RFC v2 02/12] hw/pci: Determine if rombar is explicitly enabled Akihiko Odaki
2023-12-10 4:05 ` [PATCH RFC v2 03/12] hw/pci: Do not add ROM BAR for SR-IOV VF Akihiko Odaki
2023-12-10 4:05 ` [PATCH RFC v2 04/12] vfio: Avoid inspecting option QDict for rombar Akihiko Odaki
2023-12-10 4:05 ` [PATCH RFC v2 05/12] hw/qdev: Remove opts member Akihiko Odaki
2023-12-12 10:04 ` Philippe Mathieu-Daudé
2023-12-12 11:15 ` Akihiko Odaki
2023-12-10 4:05 ` [PATCH RFC v2 06/12] pcie_sriov: Reuse SR-IOV VF device instances Akihiko Odaki
2023-12-10 4:05 ` [PATCH RFC v2 07/12] pcie_sriov: Release VFs failed to realize Akihiko Odaki
2023-12-10 4:05 ` [PATCH RFC v2 08/12] pcie_sriov: Ensure PF and VF are mutually exclusive Akihiko Odaki
2023-12-10 4:05 ` [PATCH RFC v2 09/12] pcie_sriov: Check PCI Express for SR-IOV PF Akihiko Odaki
2023-12-10 4:05 ` [PATCH RFC v2 10/12] pcie_sriov: Allow user to create SR-IOV device Akihiko Odaki
2023-12-10 4:05 ` [PATCH RFC v2 11/12] virtio-pci: Implement SR-IOV PF Akihiko Odaki
2023-12-10 4:05 ` [PATCH RFC v2 12/12] virtio-net: Implement SR-IOV VF Akihiko Odaki
2023-12-11 2:52 ` [PATCH RFC v2 00/12] virtio-net: add support for SR-IOV emulation Jason Wang
2023-12-11 5:28 ` Akihiko Odaki
2023-12-11 7:26 ` Jason Wang
2023-12-11 8:29 ` Akihiko Odaki
2023-12-12 4:12 ` Jason Wang
2023-12-12 9:34 ` Akihiko Odaki
2023-12-19 8:37 ` Yui Washizu [this message]
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=432f9b3b-2d91-4bc8-aca4-0ef3569a622e@gmail.com \
--to=yui.washidu@gmail.com \
--cc=akihiko.odaki@daynix.com \
--cc=alex.williamson@redhat.com \
--cc=berrange@redhat.com \
--cc=clg@redhat.com \
--cc=eduardo@habkost.net \
--cc=its@irrelevant.dk \
--cc=jasowang@redhat.com \
--cc=kbusch@kernel.org \
--cc=marcel.apfelbaum@gmail.com \
--cc=mst@redhat.com \
--cc=pbonzini@redhat.com \
--cc=qemu-block@nongnu.org \
--cc=qemu-devel@nongnu.org \
--cc=sriram.yagnaraman@est.tech \
/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).