Re: [PATCH] vhost-vdpa: fix use-after-free in _compat_vdpa_reset
On Wed, Oct 25, 2023 at 04:13:14PM -0700, Si-Wei Liu wrote:
> When the vhost-vdpa device is being closed, vhost_vdpa_cleanup() doesn't
> clean up the vqs pointer after free. This could lead to use-after-tree
> when _compat_vdpa_reset() tries to access the vqs that are freed already.
> Fix is to set vqs pointer to NULL at the end of vhost_vdpa_cleanup()
> after getting freed, which is guarded by atomic opened state.
>
> BUG: unable to handle page fault for address: 0001005b4af4
> #PF: supervisor read access in kernel mode
> #PF: error_code(0x) - not-present page
> PGD 16a80a067 P4D 0
> Oops: [#1] PREEMPT SMP NOPTI
> CPU: 4 PID: 40387 Comm: qemu-kvm Not tainted 6.6.0-rc7+ #3
> Hardware name: Dell Inc. PowerEdge R750/0PJ80M, BIOS 1.8.2 09/14/2022
> RIP: 0010:_compat_vdpa_reset.isra.0+0x27/0xb0 [vhost_vdpa]
> Code: 90 90 90 0f 1f 44 00 00 41 55 4c 8d ae 08 03 00 00 41 54 55 48
> 89 f5 53 4c 8b a6 00 03 00 00 48 85 ff 74 49 48 8b 07 4c 89 ef <48> 8b
> 80 88 45 00 00 48 c1 e8 08 48 83 f0 01 89 c3 e8 73 5e 9b dc
> RSP: 0018:ff73a85762073ba0 EFLAGS: 00010286
> RAX: 0001005b056c RBX: ff32b13ca6994c68 RCX: 0002
> RDX: 0001 RSI: ff32b13c07559000 RDI: ff32b13c07559308
> RBP: ff32b13c07559000 R08: R09: ff32b12ca497c0f0
> R10: ff73a85762073c58 R11: 000c106f9de3 R12: ff32b12c95b1d050
> R13: ff32b13c07559308 R14: ff32b12d0ddc5100 R15: 8002
> FS: 7fec5b8cbf80() GS:ff32b13bbfc8()
> knlGS:
> CS: 0010 DS: ES: CR0: 80050033
> CR2: 0001005b4af4 CR3: 00015644a003 CR4: 00773ee0
> PKRU: 5554
> Call Trace:
>
>? __die+0x20/0x70
>? page_fault_oops+0x76/0x170
>? exc_page_fault+0x65/0x150
>? asm_exc_page_fault+0x22/0x30
>? _compat_vdpa_reset.isra.0+0x27/0xb0 [vhost_vdpa]
>vhost_vdpa_open+0x57/0x280 [vhost_vdpa]
>? __pfx_chrdev_open+0x10/0x10
>chrdev_open+0xc6/0x260
>? __pfx_chrdev_open+0x10/0x10
>do_dentry_open+0x16e/0x530
>do_open+0x21c/0x400
>path_openat+0x111/0x290
>do_filp_open+0xb2/0x160
>? __check_object_size.part.0+0x5e/0x140
>do_sys_openat2+0x96/0xd0
>__x64_sys_openat+0x53/0xa0
>do_syscall_64+0x59/0x90
>? syscall_exit_to_user_mode+0x22/0x40
>? do_syscall_64+0x69/0x90
>? syscall_exit_to_user_mode+0x22/0x40
>? do_syscall_64+0x69/0x90
>? do_syscall_64+0x69/0x90
>? syscall_exit_to_user_mode+0x22/0x40
>? do_syscall_64+0x69/0x90
>? exc_page_fault+0x65/0x150
>entry_SYSCALL_64_after_hwframe+0x6e/0xd8
>
> Fixes: 10cbf8dfaf93 ("vhost-vdpa: clean iotlb map during reset for older
> userspace")
> Fixes: ac7e98c73c05 ("vhost-vdpa: fix NULL pointer deref in
> _compat_vdpa_reset")
So these two are all in next correct?
I really do not like it how 10cbf8dfaf936e3ef1f5d7fdc6e9dada268ba6bb
introduced a regression and then apparently we keep fixing things up?
Can I squash these 3 commits?
> Reported-by: Lei Yang
> Closes:
> https://lore.kernel.org/all/CAPpAL=yhdqn1aztecn3mps8o4m+bl_hvy02fdpihn7dwd91...@mail.gmail.com/
> Signed-off-by: Si-Wei Liu
> ---
> drivers/vhost/vdpa.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/vhost/vdpa.c b/drivers/vhost/vdpa.c
> index 9a2343c45df0..30df5c58db73 100644
> --- a/drivers/vhost/vdpa.c
> +++ b/drivers/vhost/vdpa.c
> @@ -1355,6 +1355,7 @@ static void vhost_vdpa_cleanup(struct vhost_vdpa *v)
> vhost_vdpa_free_domain(v);
> vhost_dev_cleanup(>vdev);
> kfree(v->vdev.vqs);
> + v->vdev.vqs = NULL;
> }
>
> static int vhost_vdpa_open(struct inode *inode, struct file *filep)
> --
> 2.39.3
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
Re: [PATCH v2] virtio_pci: Switch away from deprecated irq_set_affinity_hint
On Wed, 25 Oct 2023 16:53:19 +0200, Jakub Sitnicki wrote:
> Since commit 65c7cdedeb30 ("genirq: Provide new interfaces for affinity
> hints") irq_set_affinity_hint is being phased out.
>
> Switch to new interfaces for setting and applying irq affinity hints.
>
> Signed-off-by: Jakub Sitnicki
Reviewed-by: Xuan Zhuo
Thanks.
> ---
> v2:
> - Leave cpumask_copy as is. We can't pass pointer to stack memory as hint.
>Proposed a change to IRQ affinity interface to address this limitation:
>https://lore.kernel.org/r/20231025141517.375378-1-ja...@cloudflare.com
>
> v1: https://lore.kernel.org/r/20231019101625.412936-2-ja...@cloudflare.com
> ---
> drivers/virtio/virtio_pci_common.c | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/virtio/virtio_pci_common.c
> b/drivers/virtio/virtio_pci_common.c
> index c2524a7207cf..7a5593997e0e 100644
> --- a/drivers/virtio/virtio_pci_common.c
> +++ b/drivers/virtio/virtio_pci_common.c
> @@ -242,7 +242,7 @@ void vp_del_vqs(struct virtio_device *vdev)
> if (v != VIRTIO_MSI_NO_VECTOR) {
> int irq = pci_irq_vector(vp_dev->pci_dev, v);
>
> - irq_set_affinity_hint(irq, NULL);
> + irq_update_affinity_hint(irq, NULL);
> free_irq(irq, vq);
> }
> }
> @@ -443,10 +443,10 @@ int vp_set_vq_affinity(struct virtqueue *vq, const
> struct cpumask *cpu_mask)
> mask = vp_dev->msix_affinity_masks[info->msix_vector];
> irq = pci_irq_vector(vp_dev->pci_dev, info->msix_vector);
> if (!cpu_mask)
> - irq_set_affinity_hint(irq, NULL);
> + irq_update_affinity_hint(irq, NULL);
> else {
> cpumask_copy(mask, cpu_mask);
> - irq_set_affinity_hint(irq, mask);
> + irq_set_affinity_and_hint(irq, mask);
> }
> }
> return 0;
> --
> 2.41.0
>
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
Re: [PATCH v4 0/7] vdpa: decouple reset of iotlb mapping from device reset
Hi Yang Lei, Thanks for testing my patches and reporting! As for the issue, could you please try what I posted in: https://lore.kernel.org/virtualization/1698275594-19204-1-git-send-email-si-wei@oracle.com/ and let me know how it goes? Thank you very much! Thanks, -Siwei On 10/25/2023 2:41 AM, Lei Yang wrote: On Wed, Oct 25, 2023 at 1:27 AM Si-Wei Liu wrote: Hello Si-Wei Thanks a lot for testing! Please be aware that there's a follow-up fix for a potential oops in this v4 series: The first, when I did not apply this patch [1], I will also hit this patch mentioned problem. After I applied this patch, this problem will no longer to hit again. But I hit another issues, about the error messages please review the attached file. [1] https://lore.kernel.org/virtualization/1698102863-21122-1-git-send-email-si-wei@oracle.com/ My test steps: git clone https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git cd linux/ b4 am 1697880319-4937-1-git-send-email-si-wei@oracle.com b4 am 20231018171456.1624030-2-dtatu...@nvidia.com b4 am 1698102863-21122-1-git-send-email-si-wei@oracle.com git am ./v4_20231018_dtatulea_vdpa_add_support_for_vq_descriptor_mappings.mbx git am ./v4_20231021_si_wei_liu_vdpa_decouple_reset_of_iotlb_mapping_from_device_reset.mbx git am ./20231023_si_wei_liu_vhost_vdpa_fix_null_pointer_deref_in__compat_vdpa_reset.mbx cp /boot/config-5.14.0-377.el9.x86_64 .config make -j 32 make modules_install make install Thanks Lei https://lore.kernel.org/virtualization/1698102863-21122-1-git-send-email-si-wei@oracle.com/ Would be nice to have it applied for any tests. Thanks, -Siwei On 10/23/2023 11:51 PM, Lei Yang wrote: QE tested this series v4 with regression testing on real nic, there is no new regression bug. Tested-by: Lei Yang On Tue, Oct 24, 2023 at 6:02 AM Si-Wei Liu wrote: On 10/22/2023 8:51 PM, Jason Wang wrote: Hi Si-Wei: On Sat, Oct 21, 2023 at 5:28 PM Si-Wei Liu wrote: In order to reduce needlessly high setup and teardown cost of iotlb mapping during live migration, it's crucial to decouple the vhost-vdpa iotlb abstraction from the virtio device life cycle, i.e. iotlb mappings should be left intact across virtio device reset [1]. For it to work, the on-chip IOMMU parent device could implement a separate .reset_map() operation callback to restore 1:1 DMA mapping without having to resort to the .reset() callback, the latter of which is mainly used to reset virtio device state. This new .reset_map() callback will be invoked only before the vhost-vdpa driver is to be removed and detached from the vdpa bus, such that other vdpa bus drivers, e.g. virtio-vdpa, can start with 1:1 DMA mapping when they are attached. For the context, those on-chip IOMMU parent devices, create the 1:1 DMA mapping at vdpa device creation, and they would implicitly destroy the 1:1 mapping when the first .set_map or .dma_map callback is invoked. This patchset is rebased on top of the latest vhost tree. [1] Reducing vdpa migration downtime because of memory pin / maps https://www.mail-archive.com/qemu-devel@nongnu.org/msg953755.html --- v4: - Rework compatibility using new .compat_reset driver op I still think having a set_backend_feature() This will overload backend features with the role of carrying over compatibility quirks, which I tried to avoid from. While I think the .compat_reset from the v4 code just works with the backend features acknowledgement (and maybe others as well) to determine, but not directly tie it to backend features itself. These two have different implications in terms of requirement, scope and maintaining/deprecation, better to cope with compat quirks in explicit and driver visible way. or reset_map(clean=true) might be better. An explicit op might be marginally better in driver writer's point of view. Compliant driver doesn't have to bother asserting clean_map never be true so their code would never bother dealing with this case, as explained in the commit log for patch 5 "vhost-vdpa: clean iotlb map during reset for older userspace": " The separation of .compat_reset from the regular .reset allows vhost-vdpa able to know which driver had broken behavior before, so it can apply the corresponding compatibility quirk to the individual driver whenever needed. Compared to overloading the existing .reset with flags, .compat_reset won't cause any extra burden to the implementation of every compliant driver. " As it tries hard to not introduce new stuff on the bus. Honestly I don't see substantial difference between these other than the color. There's no single best solution that stands out among the 3. And I assume you already noticed it from all the above 3 approaches will have to go with backend features negotiation, that the 1st vdpa reset before backend feature negotiation will use the compliant version of .reset that doesn't clean up the map. While I don't think this nuance
[PATCH] vhost-vdpa: fix use-after-free in _compat_vdpa_reset
When the vhost-vdpa device is being closed, vhost_vdpa_cleanup() doesn't
clean up the vqs pointer after free. This could lead to use-after-tree
when _compat_vdpa_reset() tries to access the vqs that are freed already.
Fix is to set vqs pointer to NULL at the end of vhost_vdpa_cleanup()
after getting freed, which is guarded by atomic opened state.
BUG: unable to handle page fault for address: 0001005b4af4
#PF: supervisor read access in kernel mode
#PF: error_code(0x) - not-present page
PGD 16a80a067 P4D 0
Oops: [#1] PREEMPT SMP NOPTI
CPU: 4 PID: 40387 Comm: qemu-kvm Not tainted 6.6.0-rc7+ #3
Hardware name: Dell Inc. PowerEdge R750/0PJ80M, BIOS 1.8.2 09/14/2022
RIP: 0010:_compat_vdpa_reset.isra.0+0x27/0xb0 [vhost_vdpa]
Code: 90 90 90 0f 1f 44 00 00 41 55 4c 8d ae 08 03 00 00 41 54 55 48
89 f5 53 4c 8b a6 00 03 00 00 48 85 ff 74 49 48 8b 07 4c 89 ef <48> 8b
80 88 45 00 00 48 c1 e8 08 48 83 f0 01 89 c3 e8 73 5e 9b dc
RSP: 0018:ff73a85762073ba0 EFLAGS: 00010286
RAX: 0001005b056c RBX: ff32b13ca6994c68 RCX: 0002
RDX: 0001 RSI: ff32b13c07559000 RDI: ff32b13c07559308
RBP: ff32b13c07559000 R08: R09: ff32b12ca497c0f0
R10: ff73a85762073c58 R11: 000c106f9de3 R12: ff32b12c95b1d050
R13: ff32b13c07559308 R14: ff32b12d0ddc5100 R15: 8002
FS: 7fec5b8cbf80() GS:ff32b13bbfc8()
knlGS:
CS: 0010 DS: ES: CR0: 80050033
CR2: 0001005b4af4 CR3: 00015644a003 CR4: 00773ee0
PKRU: 5554
Call Trace:
? __die+0x20/0x70
? page_fault_oops+0x76/0x170
? exc_page_fault+0x65/0x150
? asm_exc_page_fault+0x22/0x30
? _compat_vdpa_reset.isra.0+0x27/0xb0 [vhost_vdpa]
vhost_vdpa_open+0x57/0x280 [vhost_vdpa]
? __pfx_chrdev_open+0x10/0x10
chrdev_open+0xc6/0x260
? __pfx_chrdev_open+0x10/0x10
do_dentry_open+0x16e/0x530
do_open+0x21c/0x400
path_openat+0x111/0x290
do_filp_open+0xb2/0x160
? __check_object_size.part.0+0x5e/0x140
do_sys_openat2+0x96/0xd0
__x64_sys_openat+0x53/0xa0
do_syscall_64+0x59/0x90
? syscall_exit_to_user_mode+0x22/0x40
? do_syscall_64+0x69/0x90
? syscall_exit_to_user_mode+0x22/0x40
? do_syscall_64+0x69/0x90
? do_syscall_64+0x69/0x90
? syscall_exit_to_user_mode+0x22/0x40
? do_syscall_64+0x69/0x90
? exc_page_fault+0x65/0x150
entry_SYSCALL_64_after_hwframe+0x6e/0xd8
Fixes: 10cbf8dfaf93 ("vhost-vdpa: clean iotlb map during reset for older
userspace")
Fixes: ac7e98c73c05 ("vhost-vdpa: fix NULL pointer deref in _compat_vdpa_reset")
Reported-by: Lei Yang
Closes:
https://lore.kernel.org/all/CAPpAL=yhdqn1aztecn3mps8o4m+bl_hvy02fdpihn7dwd91...@mail.gmail.com/
Signed-off-by: Si-Wei Liu
---
drivers/vhost/vdpa.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/vhost/vdpa.c b/drivers/vhost/vdpa.c
index 9a2343c45df0..30df5c58db73 100644
--- a/drivers/vhost/vdpa.c
+++ b/drivers/vhost/vdpa.c
@@ -1355,6 +1355,7 @@ static void vhost_vdpa_cleanup(struct vhost_vdpa *v)
vhost_vdpa_free_domain(v);
vhost_dev_cleanup(>vdev);
kfree(v->vdev.vqs);
+ v->vdev.vqs = NULL;
}
static int vhost_vdpa_open(struct inode *inode, struct file *filep)
--
2.39.3
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
Re: [PATCH V1 vfio 9/9] vfio/virtio: Introduce a vfio driver over virtio devices
On Wed, 25 Oct 2023 17:35:51 +0300 Yishai Hadas wrote: > On 24/10/2023 22:57, Alex Williamson wrote: > > On Tue, 17 Oct 2023 16:42:17 +0300 > > Yishai Hadas wrote: > > > >> Introduce a vfio driver over virtio devices to support the legacy > >> interface functionality for VFs. > >> > >> Background, from the virtio spec [1]. > >> > >> In some systems, there is a need to support a virtio legacy driver with > >> a device that does not directly support the legacy interface. In such > >> scenarios, a group owner device can provide the legacy interface > >> functionality for the group member devices. The driver of the owner > >> device can then access the legacy interface of a member device on behalf > >> of the legacy member device driver. > >> > >> For example, with the SR-IOV group type, group members (VFs) can not > >> present the legacy interface in an I/O BAR in BAR0 as expected by the > >> legacy pci driver. If the legacy driver is running inside a virtual > >> machine, the hypervisor executing the virtual machine can present a > >> virtual device with an I/O BAR in BAR0. The hypervisor intercepts the > >> legacy driver accesses to this I/O BAR and forwards them to the group > >> owner device (PF) using group administration commands. > >> > >> > >> Specifically, this driver adds support for a virtio-net VF to be exposed > >> as a transitional device to a guest driver and allows the legacy IO BAR > >> functionality on top. > >> > >> This allows a VM which uses a legacy virtio-net driver in the guest to > >> work transparently over a VF which its driver in the host is that new > >> driver. > >> > >> The driver can be extended easily to support some other types of virtio > >> devices (e.g virtio-blk), by adding in a few places the specific type > >> properties as was done for virtio-net. > >> > >> For now, only the virtio-net use case was tested and as such we introduce > >> the support only for such a device. > >> > >> Practically, > >> Upon probing a VF for a virtio-net device, in case its PF supports > >> legacy access over the virtio admin commands and the VF doesn't have BAR > >> 0, we set some specific 'vfio_device_ops' to be able to simulate in SW a > >> transitional device with I/O BAR in BAR 0. > >> > >> The existence of the simulated I/O bar is reported later on by > >> overwriting the VFIO_DEVICE_GET_REGION_INFO command and the device > >> exposes itself as a transitional device by overwriting some properties > >> upon reading its config space. > >> > >> Once we report the existence of I/O BAR as BAR 0 a legacy driver in the > >> guest may use it via read/write calls according to the virtio > >> specification. > >> > >> Any read/write towards the control parts of the BAR will be captured by > >> the new driver and will be translated into admin commands towards the > >> device. > >> > >> Any data path read/write access (i.e. virtio driver notifications) will > >> be forwarded to the physical BAR which its properties were supplied by > >> the admin command VIRTIO_ADMIN_CMD_LEGACY_NOTIFY_INFO upon the > >> probing/init flow. > >> > >> With that code in place a legacy driver in the guest has the look and > >> feel as if having a transitional device with legacy support for both its > >> control and data path flows. > >> > >> [1] > >> https://github.com/oasis-tcs/virtio-spec/commit/03c2d32e5093ca9f2a17797242fbef88efe94b8c > >> > >> Signed-off-by: Yishai Hadas > >> --- > >> MAINTAINERS | 7 + > >> drivers/vfio/pci/Kconfig | 2 + > >> drivers/vfio/pci/Makefile| 2 + > >> drivers/vfio/pci/virtio/Kconfig | 15 + > >> drivers/vfio/pci/virtio/Makefile | 4 + > >> drivers/vfio/pci/virtio/main.c | 577 +++ > >> 6 files changed, 607 insertions(+) > >> create mode 100644 drivers/vfio/pci/virtio/Kconfig > >> create mode 100644 drivers/vfio/pci/virtio/Makefile > >> create mode 100644 drivers/vfio/pci/virtio/main.c > >> > >> diff --git a/MAINTAINERS b/MAINTAINERS > >> index 7a7bd8bd80e9..680a70063775 100644 > >> --- a/MAINTAINERS > >> +++ b/MAINTAINERS > >> @@ -22620,6 +22620,13 @@ L:k...@vger.kernel.org > >> S: Maintained > >> F: drivers/vfio/pci/mlx5/ > >> > >> +VFIO VIRTIO PCI DRIVER > >> +M:Yishai Hadas > >> +L:k...@vger.kernel.org > >> +L:virtualization@lists.linux-foundation.org > >> +S:Maintained > >> +F:drivers/vfio/pci/virtio > >> + > >> VFIO PCI DEVICE SPECIFIC DRIVERS > >> R: Jason Gunthorpe > >> R: Yishai Hadas > >> diff --git a/drivers/vfio/pci/Kconfig b/drivers/vfio/pci/Kconfig > >> index 8125e5f37832..18c397df566d 100644 > >> --- a/drivers/vfio/pci/Kconfig > >> +++ b/drivers/vfio/pci/Kconfig > >> @@ -65,4 +65,6 @@ source "drivers/vfio/pci/hisilicon/Kconfig" > >> > >> source
Re: [PATCH V1 vfio 6/9] virtio-pci: Introduce APIs to execute legacy IO admin commands
On Wed, Oct 25, 2023 at 05:03:55PM +0300, Yishai Hadas wrote: > > Yes - I think some kind of API will be needed to setup/cleanup. > > Then 1st call to setup would do the list/use dance? some ref counting? > > OK, we may work to come in V2 with that option in place. > > Please note that the initialization 'list/use' commands would be done as > part of the admin queue activation but we can't enable the admin queue for > the upper layers before that it was done. I don't know what does this mean. > So, we may consider skipping the ref count set/get as part of the > initialization flow with some flag/detection of the list/use commands as the > ref count setting enables the admin queue for upper-layers which we would > like to prevent by that time. You can init on 1st use but you can't destroy after last use. For symmetry it's better to just have explicit constructor/destructor. > > > > And maybe the API should just be > > bool virtio_pci_admin_has_legacy_io() > > This can work as well. > > In that case, the API will just get the VF PCI to get from it the PF + > 'admin_queue' context and will check internally that all current 5 legacy > commands are supported. > > Yishai Yes, makes sense. -- MST ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/virtualization
Re: [PATCH V1 vfio 9/9] vfio/virtio: Introduce a vfio driver over virtio devices
On Wed, Oct 25, 2023 at 05:35:51PM +0300, Yishai Hadas wrote: > > Do we want to make this only probe the correct subsystem vendor ID or do > > we want to emulate the subsystem vendor ID as well? I don't see this is > > correct without one of those options. > > Looking in the 1.x spec we can see the below. > > Legacy Interfaces: A Note on PCI Device Discovery > > "Transitional devices MUST have the PCI Subsystem > Device ID matching the Virtio Device ID, as indicated in section 5 ... > This is to match legacy drivers." > > However, there is no need to enforce Subsystem Vendor ID. > > This is what we followed here. > > Makes sense ? Won't work for legacy windows drivers. -- MST ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/virtualization
[PATCH v2] virtio_pci: Switch away from deprecated irq_set_affinity_hint
Since commit 65c7cdedeb30 ("genirq: Provide new interfaces for affinity
hints") irq_set_affinity_hint is being phased out.
Switch to new interfaces for setting and applying irq affinity hints.
Signed-off-by: Jakub Sitnicki
---
v2:
- Leave cpumask_copy as is. We can't pass pointer to stack memory as hint.
Proposed a change to IRQ affinity interface to address this limitation:
https://lore.kernel.org/r/20231025141517.375378-1-ja...@cloudflare.com
v1: https://lore.kernel.org/r/20231019101625.412936-2-ja...@cloudflare.com
---
drivers/virtio/virtio_pci_common.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/virtio/virtio_pci_common.c
b/drivers/virtio/virtio_pci_common.c
index c2524a7207cf..7a5593997e0e 100644
--- a/drivers/virtio/virtio_pci_common.c
+++ b/drivers/virtio/virtio_pci_common.c
@@ -242,7 +242,7 @@ void vp_del_vqs(struct virtio_device *vdev)
if (v != VIRTIO_MSI_NO_VECTOR) {
int irq = pci_irq_vector(vp_dev->pci_dev, v);
- irq_set_affinity_hint(irq, NULL);
+ irq_update_affinity_hint(irq, NULL);
free_irq(irq, vq);
}
}
@@ -443,10 +443,10 @@ int vp_set_vq_affinity(struct virtqueue *vq, const struct
cpumask *cpu_mask)
mask = vp_dev->msix_affinity_masks[info->msix_vector];
irq = pci_irq_vector(vp_dev->pci_dev, info->msix_vector);
if (!cpu_mask)
- irq_set_affinity_hint(irq, NULL);
+ irq_update_affinity_hint(irq, NULL);
else {
cpumask_copy(mask, cpu_mask);
- irq_set_affinity_hint(irq, mask);
+ irq_set_affinity_and_hint(irq, mask);
}
}
return 0;
--
2.41.0
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
Re: [PATCH V1 vfio 9/9] vfio/virtio: Introduce a vfio driver over virtio devices
On 24/10/2023 22:57, Alex Williamson wrote: On Tue, 17 Oct 2023 16:42:17 +0300 Yishai Hadas wrote: Introduce a vfio driver over virtio devices to support the legacy interface functionality for VFs. Background, from the virtio spec [1]. In some systems, there is a need to support a virtio legacy driver with a device that does not directly support the legacy interface. In such scenarios, a group owner device can provide the legacy interface functionality for the group member devices. The driver of the owner device can then access the legacy interface of a member device on behalf of the legacy member device driver. For example, with the SR-IOV group type, group members (VFs) can not present the legacy interface in an I/O BAR in BAR0 as expected by the legacy pci driver. If the legacy driver is running inside a virtual machine, the hypervisor executing the virtual machine can present a virtual device with an I/O BAR in BAR0. The hypervisor intercepts the legacy driver accesses to this I/O BAR and forwards them to the group owner device (PF) using group administration commands. Specifically, this driver adds support for a virtio-net VF to be exposed as a transitional device to a guest driver and allows the legacy IO BAR functionality on top. This allows a VM which uses a legacy virtio-net driver in the guest to work transparently over a VF which its driver in the host is that new driver. The driver can be extended easily to support some other types of virtio devices (e.g virtio-blk), by adding in a few places the specific type properties as was done for virtio-net. For now, only the virtio-net use case was tested and as such we introduce the support only for such a device. Practically, Upon probing a VF for a virtio-net device, in case its PF supports legacy access over the virtio admin commands and the VF doesn't have BAR 0, we set some specific 'vfio_device_ops' to be able to simulate in SW a transitional device with I/O BAR in BAR 0. The existence of the simulated I/O bar is reported later on by overwriting the VFIO_DEVICE_GET_REGION_INFO command and the device exposes itself as a transitional device by overwriting some properties upon reading its config space. Once we report the existence of I/O BAR as BAR 0 a legacy driver in the guest may use it via read/write calls according to the virtio specification. Any read/write towards the control parts of the BAR will be captured by the new driver and will be translated into admin commands towards the device. Any data path read/write access (i.e. virtio driver notifications) will be forwarded to the physical BAR which its properties were supplied by the admin command VIRTIO_ADMIN_CMD_LEGACY_NOTIFY_INFO upon the probing/init flow. With that code in place a legacy driver in the guest has the look and feel as if having a transitional device with legacy support for both its control and data path flows. [1] https://github.com/oasis-tcs/virtio-spec/commit/03c2d32e5093ca9f2a17797242fbef88efe94b8c Signed-off-by: Yishai Hadas --- MAINTAINERS | 7 + drivers/vfio/pci/Kconfig | 2 + drivers/vfio/pci/Makefile| 2 + drivers/vfio/pci/virtio/Kconfig | 15 + drivers/vfio/pci/virtio/Makefile | 4 + drivers/vfio/pci/virtio/main.c | 577 +++ 6 files changed, 607 insertions(+) create mode 100644 drivers/vfio/pci/virtio/Kconfig create mode 100644 drivers/vfio/pci/virtio/Makefile create mode 100644 drivers/vfio/pci/virtio/main.c diff --git a/MAINTAINERS b/MAINTAINERS index 7a7bd8bd80e9..680a70063775 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -22620,6 +22620,13 @@ L: k...@vger.kernel.org S:Maintained F:drivers/vfio/pci/mlx5/ +VFIO VIRTIO PCI DRIVER +M: Yishai Hadas +L: k...@vger.kernel.org +L: virtualization@lists.linux-foundation.org +S: Maintained +F: drivers/vfio/pci/virtio + VFIO PCI DEVICE SPECIFIC DRIVERS R:Jason Gunthorpe R:Yishai Hadas diff --git a/drivers/vfio/pci/Kconfig b/drivers/vfio/pci/Kconfig index 8125e5f37832..18c397df566d 100644 --- a/drivers/vfio/pci/Kconfig +++ b/drivers/vfio/pci/Kconfig @@ -65,4 +65,6 @@ source "drivers/vfio/pci/hisilicon/Kconfig" source "drivers/vfio/pci/pds/Kconfig" +source "drivers/vfio/pci/virtio/Kconfig" + endmenu diff --git a/drivers/vfio/pci/Makefile b/drivers/vfio/pci/Makefile index 45167be462d8..046139a4eca5 100644 --- a/drivers/vfio/pci/Makefile +++ b/drivers/vfio/pci/Makefile @@ -13,3 +13,5 @@ obj-$(CONFIG_MLX5_VFIO_PCI) += mlx5/ obj-$(CONFIG_HISI_ACC_VFIO_PCI) += hisilicon/ obj-$(CONFIG_PDS_VFIO_PCI) += pds/ + +obj-$(CONFIG_VIRTIO_VFIO_PCI) += virtio/ diff --git a/drivers/vfio/pci/virtio/Kconfig b/drivers/vfio/pci/virtio/Kconfig new file mode 100644 index ..89eddce8b1bd --- /dev/null +++
Re: [PATCH V1 vfio 6/9] virtio-pci: Introduce APIs to execute legacy IO admin commands
On 25/10/2023 16:44, Michael S. Tsirkin wrote:
On Wed, Oct 25, 2023 at 04:00:43PM +0300, Yishai Hadas wrote:
On 25/10/2023 13:17, Michael S. Tsirkin wrote:
On Wed, Oct 25, 2023 at 12:18:32PM +0300, Yishai Hadas wrote:
On 25/10/2023 0:01, Michael S. Tsirkin wrote:
On Tue, Oct 17, 2023 at 04:42:14PM +0300, Yishai Hadas wrote:
Introduce APIs to execute legacy IO admin commands.
It includes: list_query/use, io_legacy_read/write,
io_legacy_notify_info.
Those APIs will be used by the next patches from this series.
Signed-off-by: Yishai Hadas
---
drivers/virtio/virtio_pci_common.c | 11 ++
drivers/virtio/virtio_pci_common.h | 2 +
drivers/virtio/virtio_pci_modern.c | 206
+
include/linux/virtio_pci_admin.h | 18 +++
4 files changed, 237 insertions(+)
create mode 100644 include/linux/virtio_pci_admin.h
diff --git a/drivers/virtio/virtio_pci_common.c
b/drivers/virtio/virtio_pci_common.c
index 6b4766d5abe6..212d68401d2c 100644
--- a/drivers/virtio/virtio_pci_common.c
+++ b/drivers/virtio/virtio_pci_common.c
@@ -645,6 +645,17 @@ static struct pci_driver virtio_pci_driver = {
.sriov_configure = virtio_pci_sriov_configure,
};
+struct virtio_device *virtio_pci_vf_get_pf_dev(struct pci_dev *pdev)
+{
+ struct virtio_pci_device *pf_vp_dev;
+
+ pf_vp_dev = pci_iov_get_pf_drvdata(pdev, _pci_driver);
+ if (IS_ERR(pf_vp_dev))
+ return NULL;
+
+ return _vp_dev->vdev;
+}
+
module_pci_driver(virtio_pci_driver);
MODULE_AUTHOR("Anthony Liguori ");
diff --git a/drivers/virtio/virtio_pci_common.h
b/drivers/virtio/virtio_pci_common.h
index a21b9ba01a60..2785e61ed668 100644
--- a/drivers/virtio/virtio_pci_common.h
+++ b/drivers/virtio/virtio_pci_common.h
@@ -155,4 +155,6 @@ static inline void
virtio_pci_legacy_remove(struct virtio_pci_device *vp_dev)
int virtio_pci_modern_probe(struct virtio_pci_device *);
void virtio_pci_modern_remove(struct virtio_pci_device *);
+struct virtio_device *virtio_pci_vf_get_pf_dev(struct pci_dev *pdev);
+
#endif
diff --git a/drivers/virtio/virtio_pci_modern.c
b/drivers/virtio/virtio_pci_modern.c
index cc159a8e6c70..00b65e20b2f5 100644
--- a/drivers/virtio/virtio_pci_modern.c
+++ b/drivers/virtio/virtio_pci_modern.c
@@ -719,6 +719,212 @@ static void vp_modern_destroy_avq(struct
virtio_device *vdev)
vp_dev->del_vq(_dev->admin_vq.info);
}
+/*
+ * virtio_pci_admin_list_query - Provides to driver list of commands
+ * supported for the PCI VF.
+ * @dev: VF pci_dev
+ * @buf: buffer to hold the returned list
+ * @buf_size: size of the given buffer
+ *
+ * Returns 0 on success, or negative on failure.
+ */
+int virtio_pci_admin_list_query(struct pci_dev *pdev, u8 *buf, int
buf_size)
+{
+ struct virtio_device *virtio_dev =
virtio_pci_vf_get_pf_dev(pdev);
+ struct virtio_admin_cmd cmd = {};
+ struct scatterlist result_sg;
+
+ if (!virtio_dev)
+ return -ENODEV;
+
+ sg_init_one(_sg, buf, buf_size);
+ cmd.opcode = cpu_to_le16(VIRTIO_ADMIN_CMD_LIST_QUERY);
+ cmd.group_type = cpu_to_le16(VIRTIO_ADMIN_GROUP_TYPE_SRIOV);
+ cmd.result_sg = _sg;
+
+ return vp_modern_admin_cmd_exec(virtio_dev, );
+}
+EXPORT_SYMBOL_GPL(virtio_pci_admin_list_query);
+
+/*
+ * virtio_pci_admin_list_use - Provides to device list of commands
+ * used for the PCI VF.
+ * @dev: VF pci_dev
+ * @buf: buffer which holds the list
+ * @buf_size: size of the given buffer
+ *
+ * Returns 0 on success, or negative on failure.
+ */
+int virtio_pci_admin_list_use(struct pci_dev *pdev, u8 *buf, int
buf_size)
+{
+ struct virtio_device *virtio_dev =
virtio_pci_vf_get_pf_dev(pdev);
+ struct virtio_admin_cmd cmd = {};
+ struct scatterlist data_sg;
+
+ if (!virtio_dev)
+ return -ENODEV;
+
+ sg_init_one(_sg, buf, buf_size);
+ cmd.opcode = cpu_to_le16(VIRTIO_ADMIN_CMD_LIST_USE);
+ cmd.group_type = cpu_to_le16(VIRTIO_ADMIN_GROUP_TYPE_SRIOV);
+
Re: [PATCH v3 1/5] x86/paravirt: move some functions and defines to alternative
On 25.10.23 15:44, Borislav Petkov wrote:
On Wed, Oct 25, 2023 at 03:31:07PM +0200, Juergen Gross wrote:
There is
#define nop() asm volatile ("nop")
in arch/x86/include/asm/special_insns.h already.
Then call it "nop_func" or so.
Okay.
It might not be needed now, but are you sure we won't need it in future?
No, I'm not.
What I'm sure of is: stuff should be added to the kernel only when
really needed. Not in the expectation that it might potentially be
needed at some point.
Will double check whether it is needed now.
Juergen
OpenPGP_0xB0DE9DD628BF132F.asc
Description: OpenPGP public key
OpenPGP_signature.asc
Description: OpenPGP digital signature
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
Re: [PATCH v3 1/5] x86/paravirt: move some functions and defines to alternative
On Wed, Oct 25, 2023 at 03:31:07PM +0200, Juergen Gross wrote:
> There is
>
> #define nop() asm volatile ("nop")
>
> in arch/x86/include/asm/special_insns.h already.
Then call it "nop_func" or so.
> It might not be needed now, but are you sure we won't need it in future?
No, I'm not.
What I'm sure of is: stuff should be added to the kernel only when
really needed. Not in the expectation that it might potentially be
needed at some point.
Thx.
--
Regards/Gruss,
Boris.
https://people.kernel.org/tglx/notes-about-netiquette
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
Re: [PATCH V1 vfio 6/9] virtio-pci: Introduce APIs to execute legacy IO admin commands
On Wed, Oct 25, 2023 at 04:00:43PM +0300, Yishai Hadas wrote:
> On 25/10/2023 13:17, Michael S. Tsirkin wrote:
> > On Wed, Oct 25, 2023 at 12:18:32PM +0300, Yishai Hadas wrote:
> > > On 25/10/2023 0:01, Michael S. Tsirkin wrote:
> > >
> > > On Tue, Oct 17, 2023 at 04:42:14PM +0300, Yishai Hadas wrote:
> > >
> > > Introduce APIs to execute legacy IO admin commands.
> > >
> > > It includes: list_query/use, io_legacy_read/write,
> > > io_legacy_notify_info.
> > >
> > > Those APIs will be used by the next patches from this series.
> > >
> > > Signed-off-by: Yishai Hadas
> > > ---
> > > drivers/virtio/virtio_pci_common.c | 11 ++
> > > drivers/virtio/virtio_pci_common.h | 2 +
> > > drivers/virtio/virtio_pci_modern.c | 206
> > > +
> > > include/linux/virtio_pci_admin.h | 18 +++
> > > 4 files changed, 237 insertions(+)
> > > create mode 100644 include/linux/virtio_pci_admin.h
> > >
> > > diff --git a/drivers/virtio/virtio_pci_common.c
> > > b/drivers/virtio/virtio_pci_common.c
> > > index 6b4766d5abe6..212d68401d2c 100644
> > > --- a/drivers/virtio/virtio_pci_common.c
> > > +++ b/drivers/virtio/virtio_pci_common.c
> > > @@ -645,6 +645,17 @@ static struct pci_driver virtio_pci_driver
> > > = {
> > > .sriov_configure = virtio_pci_sriov_configure,
> > > };
> > >
> > > +struct virtio_device *virtio_pci_vf_get_pf_dev(struct pci_dev
> > > *pdev)
> > > +{
> > > + struct virtio_pci_device *pf_vp_dev;
> > > +
> > > + pf_vp_dev = pci_iov_get_pf_drvdata(pdev,
> > > _pci_driver);
> > > + if (IS_ERR(pf_vp_dev))
> > > + return NULL;
> > > +
> > > + return _vp_dev->vdev;
> > > +}
> > > +
> > > module_pci_driver(virtio_pci_driver);
> > >
> > > MODULE_AUTHOR("Anthony Liguori ");
> > > diff --git a/drivers/virtio/virtio_pci_common.h
> > > b/drivers/virtio/virtio_pci_common.h
> > > index a21b9ba01a60..2785e61ed668 100644
> > > --- a/drivers/virtio/virtio_pci_common.h
> > > +++ b/drivers/virtio/virtio_pci_common.h
> > > @@ -155,4 +155,6 @@ static inline void
> > > virtio_pci_legacy_remove(struct virtio_pci_device *vp_dev)
> > > int virtio_pci_modern_probe(struct virtio_pci_device *);
> > > void virtio_pci_modern_remove(struct virtio_pci_device *);
> > >
> > > +struct virtio_device *virtio_pci_vf_get_pf_dev(struct pci_dev
> > > *pdev);
> > > +
> > > #endif
> > > diff --git a/drivers/virtio/virtio_pci_modern.c
> > > b/drivers/virtio/virtio_pci_modern.c
> > > index cc159a8e6c70..00b65e20b2f5 100644
> > > --- a/drivers/virtio/virtio_pci_modern.c
> > > +++ b/drivers/virtio/virtio_pci_modern.c
> > > @@ -719,6 +719,212 @@ static void vp_modern_destroy_avq(struct
> > > virtio_device *vdev)
> > > vp_dev->del_vq(_dev->admin_vq.info);
> > > }
> > >
> > > +/*
> > > + * virtio_pci_admin_list_query - Provides to driver list of
> > > commands
> > > + * supported for the PCI VF.
> > > + * @dev: VF pci_dev
> > > + * @buf: buffer to hold the returned list
> > > + * @buf_size: size of the given buffer
> > > + *
> > > + * Returns 0 on success, or negative on failure.
> > > + */
> > > +int virtio_pci_admin_list_query(struct pci_dev *pdev, u8 *buf,
> > > int buf_size)
> > > +{
> > > + struct virtio_device *virtio_dev =
> > > virtio_pci_vf_get_pf_dev(pdev);
> > > + struct virtio_admin_cmd cmd = {};
> > > + struct scatterlist result_sg;
> > > +
> > > + if (!virtio_dev)
> > > + return -ENODEV;
> > > +
> > > + sg_init_one(_sg, buf, buf_size);
> > > + cmd.opcode = cpu_to_le16(VIRTIO_ADMIN_CMD_LIST_QUERY);
> > > + cmd.group_type =
> > > cpu_to_le16(VIRTIO_ADMIN_GROUP_TYPE_SRIOV);
> > > + cmd.result_sg = _sg;
> > > +
> > > + return vp_modern_admin_cmd_exec(virtio_dev, );
> > > +}
> > > +EXPORT_SYMBOL_GPL(virtio_pci_admin_list_query);
> > > +
> > > +/*
> > > + * virtio_pci_admin_list_use - Provides to device list of
> > > commands
> > > + * used for the PCI VF.
> > > + * @dev: VF pci_dev
> > > + * @buf: buffer which holds the list
> > > + * @buf_size: size of the given buffer
> > > + *
> > > + * Returns 0 on success, or negative on failure.
> > > + */
> > > +int virtio_pci_admin_list_use(struct pci_dev
Re: [PATCH v3 1/5] x86/paravirt: move some functions and defines to alternative
On 25.10.23 12:34, Borislav Petkov wrote:
On Thu, Oct 19, 2023 at 11:15:16AM +0200, Juergen Gross wrote:
+/* Low-level backend functions usable from alternative code replacements. */
+DEFINE_ASM_FUNC(x86_nop, "", .entry.text);
+EXPORT_SYMBOL_GPL(x86_nop);
This is all x86 code so you don't really need the "x86_" prefix - "nop"
is perfectly fine.
There is
#define nop() asm volatile ("nop")
in arch/x86/include/asm/special_insns.h already.
+noinstr void x86_BUG(void)
+{
+ BUG();
+}
+EXPORT_SYMBOL_GPL(x86_BUG);
That export is needed for?
Paravirt stuff in modules?
It builds here without it - I guess I need to do an allmodconfig.
It might not be needed now, but are you sure we won't need it in future?
Juergen
OpenPGP_0xB0DE9DD628BF132F.asc
Description: OpenPGP public key
OpenPGP_signature.asc
Description: OpenPGP digital signature
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
Re: [PATCH V1 vfio 6/9] virtio-pci: Introduce APIs to execute legacy IO admin commands
On Wed, Oct 25, 2023 at 04:00:43PM +0300, Yishai Hadas wrote:
> On 25/10/2023 13:17, Michael S. Tsirkin wrote:
> > On Wed, Oct 25, 2023 at 12:18:32PM +0300, Yishai Hadas wrote:
> > > On 25/10/2023 0:01, Michael S. Tsirkin wrote:
> > >
> > > On Tue, Oct 17, 2023 at 04:42:14PM +0300, Yishai Hadas wrote:
> > >
> > > Introduce APIs to execute legacy IO admin commands.
> > >
> > > It includes: list_query/use, io_legacy_read/write,
> > > io_legacy_notify_info.
> > >
> > > Those APIs will be used by the next patches from this series.
> > >
> > > Signed-off-by: Yishai Hadas
> > > ---
> > > drivers/virtio/virtio_pci_common.c | 11 ++
> > > drivers/virtio/virtio_pci_common.h | 2 +
> > > drivers/virtio/virtio_pci_modern.c | 206
> > > +
> > > include/linux/virtio_pci_admin.h | 18 +++
> > > 4 files changed, 237 insertions(+)
> > > create mode 100644 include/linux/virtio_pci_admin.h
> > >
> > > diff --git a/drivers/virtio/virtio_pci_common.c
> > > b/drivers/virtio/virtio_pci_common.c
> > > index 6b4766d5abe6..212d68401d2c 100644
> > > --- a/drivers/virtio/virtio_pci_common.c
> > > +++ b/drivers/virtio/virtio_pci_common.c
> > > @@ -645,6 +645,17 @@ static struct pci_driver virtio_pci_driver
> > > = {
> > > .sriov_configure = virtio_pci_sriov_configure,
> > > };
> > >
> > > +struct virtio_device *virtio_pci_vf_get_pf_dev(struct pci_dev
> > > *pdev)
> > > +{
> > > + struct virtio_pci_device *pf_vp_dev;
> > > +
> > > + pf_vp_dev = pci_iov_get_pf_drvdata(pdev,
> > > _pci_driver);
> > > + if (IS_ERR(pf_vp_dev))
> > > + return NULL;
> > > +
> > > + return _vp_dev->vdev;
> > > +}
> > > +
> > > module_pci_driver(virtio_pci_driver);
> > >
> > > MODULE_AUTHOR("Anthony Liguori ");
> > > diff --git a/drivers/virtio/virtio_pci_common.h
> > > b/drivers/virtio/virtio_pci_common.h
> > > index a21b9ba01a60..2785e61ed668 100644
> > > --- a/drivers/virtio/virtio_pci_common.h
> > > +++ b/drivers/virtio/virtio_pci_common.h
> > > @@ -155,4 +155,6 @@ static inline void
> > > virtio_pci_legacy_remove(struct virtio_pci_device *vp_dev)
> > > int virtio_pci_modern_probe(struct virtio_pci_device *);
> > > void virtio_pci_modern_remove(struct virtio_pci_device *);
> > >
> > > +struct virtio_device *virtio_pci_vf_get_pf_dev(struct pci_dev
> > > *pdev);
> > > +
> > > #endif
> > > diff --git a/drivers/virtio/virtio_pci_modern.c
> > > b/drivers/virtio/virtio_pci_modern.c
> > > index cc159a8e6c70..00b65e20b2f5 100644
> > > --- a/drivers/virtio/virtio_pci_modern.c
> > > +++ b/drivers/virtio/virtio_pci_modern.c
> > > @@ -719,6 +719,212 @@ static void vp_modern_destroy_avq(struct
> > > virtio_device *vdev)
> > > vp_dev->del_vq(_dev->admin_vq.info);
> > > }
> > >
> > > +/*
> > > + * virtio_pci_admin_list_query - Provides to driver list of
> > > commands
> > > + * supported for the PCI VF.
> > > + * @dev: VF pci_dev
> > > + * @buf: buffer to hold the returned list
> > > + * @buf_size: size of the given buffer
> > > + *
> > > + * Returns 0 on success, or negative on failure.
> > > + */
> > > +int virtio_pci_admin_list_query(struct pci_dev *pdev, u8 *buf,
> > > int buf_size)
> > > +{
> > > + struct virtio_device *virtio_dev =
> > > virtio_pci_vf_get_pf_dev(pdev);
> > > + struct virtio_admin_cmd cmd = {};
> > > + struct scatterlist result_sg;
> > > +
> > > + if (!virtio_dev)
> > > + return -ENODEV;
> > > +
> > > + sg_init_one(_sg, buf, buf_size);
> > > + cmd.opcode = cpu_to_le16(VIRTIO_ADMIN_CMD_LIST_QUERY);
> > > + cmd.group_type =
> > > cpu_to_le16(VIRTIO_ADMIN_GROUP_TYPE_SRIOV);
> > > + cmd.result_sg = _sg;
> > > +
> > > + return vp_modern_admin_cmd_exec(virtio_dev, );
> > > +}
> > > +EXPORT_SYMBOL_GPL(virtio_pci_admin_list_query);
> > > +
> > > +/*
> > > + * virtio_pci_admin_list_use - Provides to device list of
> > > commands
> > > + * used for the PCI VF.
> > > + * @dev: VF pci_dev
> > > + * @buf: buffer which holds the list
> > > + * @buf_size: size of the given buffer
> > > + *
> > > + * Returns 0 on success, or negative on failure.
> > > + */
> > > +int virtio_pci_admin_list_use(struct pci_dev
Re: [PATCH V1 vfio 6/9] virtio-pci: Introduce APIs to execute legacy IO admin commands
On 25/10/2023 13:17, Michael S. Tsirkin wrote:
On Wed, Oct 25, 2023 at 12:18:32PM +0300, Yishai Hadas wrote:
On 25/10/2023 0:01, Michael S. Tsirkin wrote:
On Tue, Oct 17, 2023 at 04:42:14PM +0300, Yishai Hadas wrote:
Introduce APIs to execute legacy IO admin commands.
It includes: list_query/use, io_legacy_read/write,
io_legacy_notify_info.
Those APIs will be used by the next patches from this series.
Signed-off-by: Yishai Hadas
---
drivers/virtio/virtio_pci_common.c | 11 ++
drivers/virtio/virtio_pci_common.h | 2 +
drivers/virtio/virtio_pci_modern.c | 206 +
include/linux/virtio_pci_admin.h | 18 +++
4 files changed, 237 insertions(+)
create mode 100644 include/linux/virtio_pci_admin.h
diff --git a/drivers/virtio/virtio_pci_common.c
b/drivers/virtio/virtio_pci_common.c
index 6b4766d5abe6..212d68401d2c 100644
--- a/drivers/virtio/virtio_pci_common.c
+++ b/drivers/virtio/virtio_pci_common.c
@@ -645,6 +645,17 @@ static struct pci_driver virtio_pci_driver = {
.sriov_configure = virtio_pci_sriov_configure,
};
+struct virtio_device *virtio_pci_vf_get_pf_dev(struct pci_dev *pdev)
+{
+ struct virtio_pci_device *pf_vp_dev;
+
+ pf_vp_dev = pci_iov_get_pf_drvdata(pdev, _pci_driver);
+ if (IS_ERR(pf_vp_dev))
+ return NULL;
+
+ return _vp_dev->vdev;
+}
+
module_pci_driver(virtio_pci_driver);
MODULE_AUTHOR("Anthony Liguori ");
diff --git a/drivers/virtio/virtio_pci_common.h
b/drivers/virtio/virtio_pci_common.h
index a21b9ba01a60..2785e61ed668 100644
--- a/drivers/virtio/virtio_pci_common.h
+++ b/drivers/virtio/virtio_pci_common.h
@@ -155,4 +155,6 @@ static inline void virtio_pci_legacy_remove(struct
virtio_pci_device *vp_dev)
int virtio_pci_modern_probe(struct virtio_pci_device *);
void virtio_pci_modern_remove(struct virtio_pci_device *);
+struct virtio_device *virtio_pci_vf_get_pf_dev(struct pci_dev *pdev);
+
#endif
diff --git a/drivers/virtio/virtio_pci_modern.c
b/drivers/virtio/virtio_pci_modern.c
index cc159a8e6c70..00b65e20b2f5 100644
--- a/drivers/virtio/virtio_pci_modern.c
+++ b/drivers/virtio/virtio_pci_modern.c
@@ -719,6 +719,212 @@ static void vp_modern_destroy_avq(struct
virtio_device *vdev)
vp_dev->del_vq(_dev->admin_vq.info);
}
+/*
+ * virtio_pci_admin_list_query - Provides to driver list of commands
+ * supported for the PCI VF.
+ * @dev: VF pci_dev
+ * @buf: buffer to hold the returned list
+ * @buf_size: size of the given buffer
+ *
+ * Returns 0 on success, or negative on failure.
+ */
+int virtio_pci_admin_list_query(struct pci_dev *pdev, u8 *buf, int
buf_size)
+{
+ struct virtio_device *virtio_dev =
virtio_pci_vf_get_pf_dev(pdev);
+ struct virtio_admin_cmd cmd = {};
+ struct scatterlist result_sg;
+
+ if (!virtio_dev)
+ return -ENODEV;
+
+ sg_init_one(_sg, buf, buf_size);
+ cmd.opcode = cpu_to_le16(VIRTIO_ADMIN_CMD_LIST_QUERY);
+ cmd.group_type = cpu_to_le16(VIRTIO_ADMIN_GROUP_TYPE_SRIOV);
+ cmd.result_sg = _sg;
+
+ return vp_modern_admin_cmd_exec(virtio_dev, );
+}
+EXPORT_SYMBOL_GPL(virtio_pci_admin_list_query);
+
+/*
+ * virtio_pci_admin_list_use - Provides to device list of commands
+ * used for the PCI VF.
+ * @dev: VF pci_dev
+ * @buf: buffer which holds the list
+ * @buf_size: size of the given buffer
+ *
+ * Returns 0 on success, or negative on failure.
+ */
+int virtio_pci_admin_list_use(struct pci_dev *pdev, u8 *buf, int
buf_size)
+{
+ struct virtio_device *virtio_dev =
virtio_pci_vf_get_pf_dev(pdev);
+ struct virtio_admin_cmd cmd = {};
+ struct scatterlist data_sg;
+
+ if (!virtio_dev)
+ return -ENODEV;
+
+ sg_init_one(_sg, buf, buf_size);
+ cmd.opcode = cpu_to_le16(VIRTIO_ADMIN_CMD_LIST_USE);
+ cmd.group_type = cpu_to_le16(VIRTIO_ADMIN_GROUP_TYPE_SRIOV);
+ cmd.data_sg = _sg;
+
+ return vp_modern_admin_cmd_exec(virtio_dev, );
+}
+EXPORT_SYMBOL_GPL(virtio_pci_admin_list_use);
list commands are actually for a group, not for the
Re: [PATCH v3 1/5] x86/paravirt: move some functions and defines to alternative
On Thu, Oct 19, 2023 at 11:15:16AM +0200, Juergen Gross wrote:
> +/* Low-level backend functions usable from alternative code replacements. */
> +DEFINE_ASM_FUNC(x86_nop, "", .entry.text);
> +EXPORT_SYMBOL_GPL(x86_nop);
This is all x86 code so you don't really need the "x86_" prefix - "nop"
is perfectly fine.
> +noinstr void x86_BUG(void)
> +{
> + BUG();
> +}
> +EXPORT_SYMBOL_GPL(x86_BUG);
That export is needed for?
Paravirt stuff in modules?
It builds here without it - I guess I need to do an allmodconfig.
--
Regards/Gruss,
Boris.
https://people.kernel.org/tglx/notes-about-netiquette
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
Re: [PATCH V1 vfio 6/9] virtio-pci: Introduce APIs to execute legacy IO admin commands
On Wed, Oct 25, 2023 at 12:18:32PM +0300, Yishai Hadas wrote:
> On 25/10/2023 0:01, Michael S. Tsirkin wrote:
>
> On Tue, Oct 17, 2023 at 04:42:14PM +0300, Yishai Hadas wrote:
>
> Introduce APIs to execute legacy IO admin commands.
>
> It includes: list_query/use, io_legacy_read/write,
> io_legacy_notify_info.
>
> Those APIs will be used by the next patches from this series.
>
> Signed-off-by: Yishai Hadas
> ---
> drivers/virtio/virtio_pci_common.c | 11 ++
> drivers/virtio/virtio_pci_common.h | 2 +
> drivers/virtio/virtio_pci_modern.c | 206
> +
> include/linux/virtio_pci_admin.h | 18 +++
> 4 files changed, 237 insertions(+)
> create mode 100644 include/linux/virtio_pci_admin.h
>
> diff --git a/drivers/virtio/virtio_pci_common.c
> b/drivers/virtio/virtio_pci_common.c
> index 6b4766d5abe6..212d68401d2c 100644
> --- a/drivers/virtio/virtio_pci_common.c
> +++ b/drivers/virtio/virtio_pci_common.c
> @@ -645,6 +645,17 @@ static struct pci_driver virtio_pci_driver = {
> .sriov_configure = virtio_pci_sriov_configure,
> };
>
> +struct virtio_device *virtio_pci_vf_get_pf_dev(struct pci_dev *pdev)
> +{
> + struct virtio_pci_device *pf_vp_dev;
> +
> + pf_vp_dev = pci_iov_get_pf_drvdata(pdev, _pci_driver);
> + if (IS_ERR(pf_vp_dev))
> + return NULL;
> +
> + return _vp_dev->vdev;
> +}
> +
> module_pci_driver(virtio_pci_driver);
>
> MODULE_AUTHOR("Anthony Liguori ");
> diff --git a/drivers/virtio/virtio_pci_common.h
> b/drivers/virtio/virtio_pci_common.h
> index a21b9ba01a60..2785e61ed668 100644
> --- a/drivers/virtio/virtio_pci_common.h
> +++ b/drivers/virtio/virtio_pci_common.h
> @@ -155,4 +155,6 @@ static inline void
> virtio_pci_legacy_remove(struct virtio_pci_device *vp_dev)
> int virtio_pci_modern_probe(struct virtio_pci_device *);
> void virtio_pci_modern_remove(struct virtio_pci_device *);
>
> +struct virtio_device *virtio_pci_vf_get_pf_dev(struct pci_dev *pdev);
> +
> #endif
> diff --git a/drivers/virtio/virtio_pci_modern.c
> b/drivers/virtio/virtio_pci_modern.c
> index cc159a8e6c70..00b65e20b2f5 100644
> --- a/drivers/virtio/virtio_pci_modern.c
> +++ b/drivers/virtio/virtio_pci_modern.c
> @@ -719,6 +719,212 @@ static void vp_modern_destroy_avq(struct
> virtio_device *vdev)
> vp_dev->del_vq(_dev->admin_vq.info);
> }
>
> +/*
> + * virtio_pci_admin_list_query - Provides to driver list of commands
> + * supported for the PCI VF.
> + * @dev: VF pci_dev
> + * @buf: buffer to hold the returned list
> + * @buf_size: size of the given buffer
> + *
> + * Returns 0 on success, or negative on failure.
> + */
> +int virtio_pci_admin_list_query(struct pci_dev *pdev, u8 *buf, int
> buf_size)
> +{
> + struct virtio_device *virtio_dev =
> virtio_pci_vf_get_pf_dev(pdev);
> + struct virtio_admin_cmd cmd = {};
> + struct scatterlist result_sg;
> +
> + if (!virtio_dev)
> + return -ENODEV;
> +
> + sg_init_one(_sg, buf, buf_size);
> + cmd.opcode = cpu_to_le16(VIRTIO_ADMIN_CMD_LIST_QUERY);
> + cmd.group_type = cpu_to_le16(VIRTIO_ADMIN_GROUP_TYPE_SRIOV);
> + cmd.result_sg = _sg;
> +
> + return vp_modern_admin_cmd_exec(virtio_dev, );
> +}
> +EXPORT_SYMBOL_GPL(virtio_pci_admin_list_query);
> +
> +/*
> + * virtio_pci_admin_list_use - Provides to device list of commands
> + * used for the PCI VF.
> + * @dev: VF pci_dev
> + * @buf: buffer which holds the list
> + * @buf_size: size of the given buffer
> + *
> + * Returns 0 on success, or negative on failure.
> + */
> +int virtio_pci_admin_list_use(struct pci_dev *pdev, u8 *buf, int
> buf_size)
> +{
> + struct virtio_device *virtio_dev =
> virtio_pci_vf_get_pf_dev(pdev);
> + struct virtio_admin_cmd cmd = {};
> + struct scatterlist data_sg;
> +
> + if (!virtio_dev)
> + return -ENODEV;
> +
> + sg_init_one(_sg, buf, buf_size);
> + cmd.opcode = cpu_to_le16(VIRTIO_ADMIN_CMD_LIST_USE);
> + cmd.group_type = cpu_to_le16(VIRTIO_ADMIN_GROUP_TYPE_SRIOV);
> + cmd.data_sg = _sg;
> +
> + return vp_modern_admin_cmd_exec(virtio_dev, );
> +}
>
[PATCH v4] ALSA: virtio: use ack callback
This commit uses the ack() callback to determine when a buffer has been
updated, then exposes it to guest.
The current mechanism splits a dma buffer into descriptors that are
exposed to the device. This dma buffer is shared with the user
application. When the device consumes a buffer, the driver moves the
request from the used ring to available ring.
The driver exposes the buffer to the device without knowing if the
content has been updated from the user. The section 2.8.21.1 of the
virtio spec states that: "The device MAY access the descriptor chains
the driver created and the memory they refer to immediately". If the
device picks up buffers from the available ring just after it is
notified, it happens that the content may be old.
When the ack() callback is invoked, the driver exposes only the buffers
that have already been updated, i.e., enqueued in the available ring.
Thus, the device always picks up a buffer that is updated.
For capturing, the driver starts by exposing all the available buffers
to device. After device updates the content of a buffer, it enqueues it
in the used ring. It is only after the ack() for capturing is issued
that the driver re-enqueues the buffer in the available ring.
Co-developed-by: Anton Yakovlev
Signed-off-by: Anton Yakovlev
Signed-off-by: Matias Ezequiel Vara Larsen
---
Changelog:
v3 -> v4:
* Disable rewinds
* Add SNDRV_PCM_INFO_SYNC_APPLPTR flag
* Use pcm indirect API for pointer() and ack() callbacks
v2 -> v3:
* Use ack() callback instead of copy()/fill_silence()
* Change commit name
* Rewrite commit message
* Remove virtsnd_pcm_msg_send_locked()
* Use single callback for both capture and playback
* Fix kernel test robot warnings regarding documentation
* v2 patch at:
https://lore.kernel.org/lkml/87y1fzkq8c.wl-ti...@suse.de/T/
v1 -> v2:
* Use snd_pcm_set_managed_buffer_all()for buffer allocation/freeing.
* Make virtsnd_pcm_msg_send() generic by specifying the offset and size
for the modified part of the buffer; this way no assumptions need to
be made.
* Disable SNDRV_PCM_INFO_NO_REWINDS since now only sequential
reading/writing of frames is supported.
* Correct comment at virtsnd_pcm_msg_send().
* v1 patch at:
https://lore.kernel.org/lkml/20231016151000.GE119987@fedora/t/
sound/virtio/virtio_pcm.c | 6 +-
sound/virtio/virtio_pcm.h | 9 ++-
sound/virtio/virtio_pcm_msg.c | 79 -
sound/virtio/virtio_pcm_ops.c | 125 +++---
4 files changed, 158 insertions(+), 61 deletions(-)
diff --git a/sound/virtio/virtio_pcm.c b/sound/virtio/virtio_pcm.c
index c10d91fff2fb..967e4c45be9b 100644
--- a/sound/virtio/virtio_pcm.c
+++ b/sound/virtio/virtio_pcm.c
@@ -109,7 +109,9 @@ static int virtsnd_pcm_build_hw(struct virtio_pcm_substream
*vss,
SNDRV_PCM_INFO_BATCH |
SNDRV_PCM_INFO_BLOCK_TRANSFER |
SNDRV_PCM_INFO_INTERLEAVED |
- SNDRV_PCM_INFO_PAUSE;
+ SNDRV_PCM_INFO_PAUSE |
+ SNDRV_PCM_INFO_NO_REWINDS |
+ SNDRV_PCM_INFO_SYNC_APPLPTR;
if (!info->channels_min || info->channels_min > info->channels_max) {
dev_err(>dev,
@@ -471,7 +473,7 @@ int virtsnd_pcm_build_devs(struct virtio_snd *snd)
for (kss = ks->substream; kss; kss = kss->next)
vs->substreams[kss->number]->substream = kss;
- snd_pcm_set_ops(vpcm->pcm, i, _pcm_ops);
+ snd_pcm_set_ops(vpcm->pcm, i, _pcm_ops[i]);
}
snd_pcm_set_managed_buffer_all(vpcm->pcm,
diff --git a/sound/virtio/virtio_pcm.h b/sound/virtio/virtio_pcm.h
index 062eb8e8f2cf..5dd1b43b9493 100644
--- a/sound/virtio/virtio_pcm.h
+++ b/sound/virtio/virtio_pcm.h
@@ -9,6 +9,7 @@
#include
#include
#include
+#include
struct virtio_pcm;
struct virtio_pcm_msg;
@@ -21,6 +22,7 @@ struct virtio_pcm_msg;
* @direction: Stream data flow direction (SNDRV_PCM_STREAM_XXX).
* @features: Stream VirtIO feature bit map (1 << VIRTIO_SND_PCM_F_XXX).
* @substream: Kernel ALSA substream.
+ * @pcm_indirect: Kernel indirect pcm structure.
* @hw: Kernel ALSA substream hardware descriptor.
* @elapsed_period: Kernel work to handle the elapsed period state.
* @lock: Spinlock that protects fields shared by interrupt handlers and
@@ -46,6 +48,7 @@ struct virtio_pcm_substream {
u32 direction;
u32 features;
struct snd_pcm_substream *substream;
+ struct snd_pcm_indirect pcm_indirect;
struct snd_pcm_hardware hw;
struct work_struct elapsed_period;
spinlock_t lock;
@@ -57,7 +60,6 @@ struct virtio_pcm_substream {
bool suspended;
struct virtio_pcm_msg **msgs;
unsigned int nmsgs;
- int msg_last_enqueued;
unsigned int msg_count;
wait_queue_head_t msg_empty;
};
@@ -90,7 +92,7 @@ struct virtio_pcm {
struct virtio_pcm_stream
Re: [PATCH V1 vfio 6/9] virtio-pci: Introduce APIs to execute legacy IO admin commands
Re sending as previous reply was by mistake not in a text format.
On 25/10/2023 0:01, Michael S. Tsirkin wrote:
On Tue, Oct 17, 2023 at 04:42:14PM +0300, Yishai Hadas wrote:
Introduce APIs to execute legacy IO admin commands.
It includes: list_query/use, io_legacy_read/write,
io_legacy_notify_info.
Those APIs will be used by the next patches from this series.
Signed-off-by: Yishai Hadas
---
drivers/virtio/virtio_pci_common.c | 11 ++
drivers/virtio/virtio_pci_common.h | 2 +
drivers/virtio/virtio_pci_modern.c | 206 +
include/linux/virtio_pci_admin.h | 18 +++
4 files changed, 237 insertions(+)
create mode 100644 include/linux/virtio_pci_admin.h
diff --git a/drivers/virtio/virtio_pci_common.c
b/drivers/virtio/virtio_pci_common.c
index 6b4766d5abe6..212d68401d2c 100644
--- a/drivers/virtio/virtio_pci_common.c
+++ b/drivers/virtio/virtio_pci_common.c
@@ -645,6 +645,17 @@ static struct pci_driver virtio_pci_driver = {
.sriov_configure = virtio_pci_sriov_configure,
};
+struct virtio_device *virtio_pci_vf_get_pf_dev(struct pci_dev *pdev)
+{
+ struct virtio_pci_device *pf_vp_dev;
+
+ pf_vp_dev = pci_iov_get_pf_drvdata(pdev, _pci_driver);
+ if (IS_ERR(pf_vp_dev))
+ return NULL;
+
+ return _vp_dev->vdev;
+}
+
module_pci_driver(virtio_pci_driver);
MODULE_AUTHOR("Anthony Liguori ");
diff --git a/drivers/virtio/virtio_pci_common.h
b/drivers/virtio/virtio_pci_common.h
index a21b9ba01a60..2785e61ed668 100644
--- a/drivers/virtio/virtio_pci_common.h
+++ b/drivers/virtio/virtio_pci_common.h
@@ -155,4 +155,6 @@ static inline void virtio_pci_legacy_remove(struct
virtio_pci_device *vp_dev)
int virtio_pci_modern_probe(struct virtio_pci_device *);
void virtio_pci_modern_remove(struct virtio_pci_device *);
+struct virtio_device *virtio_pci_vf_get_pf_dev(struct pci_dev *pdev);
+
#endif
diff --git a/drivers/virtio/virtio_pci_modern.c
b/drivers/virtio/virtio_pci_modern.c
index cc159a8e6c70..00b65e20b2f5 100644
--- a/drivers/virtio/virtio_pci_modern.c
+++ b/drivers/virtio/virtio_pci_modern.c
@@ -719,6 +719,212 @@ static void vp_modern_destroy_avq(struct virtio_device
*vdev)
vp_dev->del_vq(_dev->admin_vq.info);
}
+/*
+ * virtio_pci_admin_list_query - Provides to driver list of commands
+ * supported for the PCI VF.
+ * @dev: VF pci_dev
+ * @buf: buffer to hold the returned list
+ * @buf_size: size of the given buffer
+ *
+ * Returns 0 on success, or negative on failure.
+ */
+int virtio_pci_admin_list_query(struct pci_dev *pdev, u8 *buf, int buf_size)
+{
+ struct virtio_device *virtio_dev = virtio_pci_vf_get_pf_dev(pdev);
+ struct virtio_admin_cmd cmd = {};
+ struct scatterlist result_sg;
+
+ if (!virtio_dev)
+ return -ENODEV;
+
+ sg_init_one(_sg, buf, buf_size);
+ cmd.opcode = cpu_to_le16(VIRTIO_ADMIN_CMD_LIST_QUERY);
+ cmd.group_type = cpu_to_le16(VIRTIO_ADMIN_GROUP_TYPE_SRIOV);
+ cmd.result_sg = _sg;
+
+ return vp_modern_admin_cmd_exec(virtio_dev, );
+}
+EXPORT_SYMBOL_GPL(virtio_pci_admin_list_query);
+
+/*
+ * virtio_pci_admin_list_use - Provides to device list of commands
+ * used for the PCI VF.
+ * @dev: VF pci_dev
+ * @buf: buffer which holds the list
+ * @buf_size: size of the given buffer
+ *
+ * Returns 0 on success, or negative on failure.
+ */
+int virtio_pci_admin_list_use(struct pci_dev *pdev, u8 *buf, int buf_size)
+{
+ struct virtio_device *virtio_dev = virtio_pci_vf_get_pf_dev(pdev);
+ struct virtio_admin_cmd cmd = {};
+ struct scatterlist data_sg;
+
+ if (!virtio_dev)
+ return -ENODEV;
+
+ sg_init_one(_sg, buf, buf_size);
+ cmd.opcode = cpu_to_le16(VIRTIO_ADMIN_CMD_LIST_USE);
+ cmd.group_type = cpu_to_le16(VIRTIO_ADMIN_GROUP_TYPE_SRIOV);
+ cmd.data_sg = _sg;
+
+ return vp_modern_admin_cmd_exec(virtio_dev, );
+}
+EXPORT_SYMBOL_GPL(virtio_pci_admin_list_use);
list commands are actually for a group, not for the VF.
The VF was given to let the function gets the PF from it.
For now, the only existing 'group_type' in the spec is SRIOV, this is
why we hard-coded it internally to match the VF PCI.
Alternatively,
We can change the API to get the PF and 'group_type' from the caller to
better match future usage.
However, this will require to export the virtio_pci_vf_get_pf_dev() API
outside virtio-pci.
Do you prefer to change to the latter option ?
+
+/*
+ * virtio_pci_admin_legacy_io_write - Write legacy registers of a member device
+ * @dev: VF pci_dev
+ * @opcode: op code of the io write command
opcode is actually either VIRTIO_ADMIN_CMD_LEGACY_COMMON_CFG_WRITE
or VIRTIO_ADMIN_CMD_LEGACY_DEV_CFG_WRITE correct?
So please just add 2 APIs for this so users don't need to care.
Could be wrappers around these two things.
OK.
We'll export the below 2 APIs [1] which internally will call
virtio_pci_admin_legacy_io_write() with the proper op
Re: [PATCH V1 vfio 6/9] virtio-pci: Introduce APIs to execute legacy IO admin commands
On 25/10/2023 0:01, Michael S. Tsirkin wrote:
On Tue, Oct 17, 2023 at 04:42:14PM +0300, Yishai Hadas wrote:
Introduce APIs to execute legacy IO admin commands.
It includes: list_query/use, io_legacy_read/write,
io_legacy_notify_info.
Those APIs will be used by the next patches from this series.
Signed-off-by: Yishai Hadas
---
drivers/virtio/virtio_pci_common.c | 11 ++
drivers/virtio/virtio_pci_common.h | 2 +
drivers/virtio/virtio_pci_modern.c | 206 +
include/linux/virtio_pci_admin.h | 18 +++
4 files changed, 237 insertions(+)
create mode 100644 include/linux/virtio_pci_admin.h
diff --git a/drivers/virtio/virtio_pci_common.c
b/drivers/virtio/virtio_pci_common.c
index 6b4766d5abe6..212d68401d2c 100644
--- a/drivers/virtio/virtio_pci_common.c
+++ b/drivers/virtio/virtio_pci_common.c
@@ -645,6 +645,17 @@ static struct pci_driver virtio_pci_driver = {
.sriov_configure = virtio_pci_sriov_configure,
};
+struct virtio_device *virtio_pci_vf_get_pf_dev(struct pci_dev *pdev)
+{
+ struct virtio_pci_device *pf_vp_dev;
+
+ pf_vp_dev = pci_iov_get_pf_drvdata(pdev, _pci_driver);
+ if (IS_ERR(pf_vp_dev))
+ return NULL;
+
+ return _vp_dev->vdev;
+}
+
module_pci_driver(virtio_pci_driver);
MODULE_AUTHOR("Anthony Liguori");
diff --git a/drivers/virtio/virtio_pci_common.h
b/drivers/virtio/virtio_pci_common.h
index a21b9ba01a60..2785e61ed668 100644
--- a/drivers/virtio/virtio_pci_common.h
+++ b/drivers/virtio/virtio_pci_common.h
@@ -155,4 +155,6 @@ static inline void virtio_pci_legacy_remove(struct
virtio_pci_device *vp_dev)
int virtio_pci_modern_probe(struct virtio_pci_device *);
void virtio_pci_modern_remove(struct virtio_pci_device *);
+struct virtio_device *virtio_pci_vf_get_pf_dev(struct pci_dev *pdev);
+
#endif
diff --git a/drivers/virtio/virtio_pci_modern.c
b/drivers/virtio/virtio_pci_modern.c
index cc159a8e6c70..00b65e20b2f5 100644
--- a/drivers/virtio/virtio_pci_modern.c
+++ b/drivers/virtio/virtio_pci_modern.c
@@ -719,6 +719,212 @@ static void vp_modern_destroy_avq(struct virtio_device
*vdev)
vp_dev->del_vq(_dev->admin_vq.info);
}
+/*
+ * virtio_pci_admin_list_query - Provides to driver list of commands
+ * supported for the PCI VF.
+ * @dev: VF pci_dev
+ * @buf: buffer to hold the returned list
+ * @buf_size: size of the given buffer
+ *
+ * Returns 0 on success, or negative on failure.
+ */
+int virtio_pci_admin_list_query(struct pci_dev *pdev, u8 *buf, int buf_size)
+{
+ struct virtio_device *virtio_dev = virtio_pci_vf_get_pf_dev(pdev);
+ struct virtio_admin_cmd cmd = {};
+ struct scatterlist result_sg;
+
+ if (!virtio_dev)
+ return -ENODEV;
+
+ sg_init_one(_sg, buf, buf_size);
+ cmd.opcode = cpu_to_le16(VIRTIO_ADMIN_CMD_LIST_QUERY);
+ cmd.group_type = cpu_to_le16(VIRTIO_ADMIN_GROUP_TYPE_SRIOV);
+ cmd.result_sg = _sg;
+
+ return vp_modern_admin_cmd_exec(virtio_dev, );
+}
+EXPORT_SYMBOL_GPL(virtio_pci_admin_list_query);
+
+/*
+ * virtio_pci_admin_list_use - Provides to device list of commands
+ * used for the PCI VF.
+ * @dev: VF pci_dev
+ * @buf: buffer which holds the list
+ * @buf_size: size of the given buffer
+ *
+ * Returns 0 on success, or negative on failure.
+ */
+int virtio_pci_admin_list_use(struct pci_dev *pdev, u8 *buf, int buf_size)
+{
+ struct virtio_device *virtio_dev = virtio_pci_vf_get_pf_dev(pdev);
+ struct virtio_admin_cmd cmd = {};
+ struct scatterlist data_sg;
+
+ if (!virtio_dev)
+ return -ENODEV;
+
+ sg_init_one(_sg, buf, buf_size);
+ cmd.opcode = cpu_to_le16(VIRTIO_ADMIN_CMD_LIST_USE);
+ cmd.group_type = cpu_to_le16(VIRTIO_ADMIN_GROUP_TYPE_SRIOV);
+ cmd.data_sg = _sg;
+
+ return vp_modern_admin_cmd_exec(virtio_dev, );
+}
+EXPORT_SYMBOL_GPL(virtio_pci_admin_list_use);
list commands are actually for a group, not for the VF.
The VF was given to let the function gets the PF from it.
For now, the only existing 'group_type' in the spec is SRIOV, this is
why we hard-coded it internally to match the VF PCI.
Alternatively,
We can change the API to get the PF and 'group_type' from the caller to
better match future usage.
However, this will require to export the virtio_pci_vf_get_pf_dev() API
outside virtio-pci.
Do you prefer to change to the latter option ?
+
+/*
+ * virtio_pci_admin_legacy_io_write - Write legacy registers of a member device
+ * @dev: VF pci_dev
+ * @opcode: op code of the io write command
opcode is actually either VIRTIO_ADMIN_CMD_LEGACY_COMMON_CFG_WRITE
or VIRTIO_ADMIN_CMD_LEGACY_DEV_CFG_WRITE correct?
So please just add 2 APIs for this so users don't need to care.
Could be wrappers around these two things.
OK.
We'll export the below 2 APIs [1] which internally will call
virtio_pci_admin_legacy_io_write() with the proper op code hard-coded.
[1]virtio_pci_admin_legacy_device_io_write()
RE: [PATCH V1 vfio 0/9] Introduce a vfio driver over virtio devices
> From: Jason Gunthorpe > Sent: Monday, October 23, 2023 11:43 PM > > On Mon, Oct 23, 2023 at 09:33:23AM -0600, Alex Williamson wrote: > > > > Alex, > > > Are you fine to leave the provisioning of the VF including the control > > > of its transitional capability in the device hands as was suggested by > > > Jason ? > > > > If this is the standard we're going to follow, ie. profiling of a > > device is expected to occur prior to the probe of the vfio-pci variant > > driver, then we should get the out-of-tree NVIDIA vGPU driver on board > > with this too. > > Those GPU drivers are using mdev not vfio-pci.. > > mdev doesn't have a way in its uapi to configure the mdev before it is > created. > > I'm hopeful that the SIOV work will develop something better because > we clearly need it for the general use cases of SIOV beyond VFIO. > The internal idxd driver version which I looked at last time leaves provisioning via idxd's own config interface. sure let's brainstorm what'd be (if possible) a general provisioning framework after it's sent out for review. ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/virtualization
Re: [PATCH v4] vsock/virtio: initialize the_virtio_vsock before using VQs
On Tue, Oct 24, 2023 at 10:17:42PM +0300, Alexandru Matei wrote:
Once VQs are filled with empty buffers and we kick the host, it can send
connection requests. If the_virtio_vsock is not initialized before,
replies are silently dropped and do not reach the host.
virtio_transport_send_pkt() can queue packets once the_virtio_vsock is
set, but they won't be processed until vsock->tx_run is set to true. We
queue vsock->send_pkt_work when initialization finishes to send those
packets queued earlier.
Fixes: 0deab087b16a ("vsock/virtio: use RCU to avoid use-after-free on
the_virtio_vsock")
Signed-off-by: Alexandru Matei
---
v4:
- moved queue_work for send_pkt_work in vqs_start and added comment explaining
why
v3:
- renamed vqs_fill to vqs_start and moved tx_run initialization to it
- queued send_pkt_work at the end of initialization to send packets queued
earlier
v2:
- split virtio_vsock_vqs_init in vqs_init and vqs_fill and moved
the_virtio_vsock initialization after vqs_init
net/vmw_vsock/virtio_transport.c | 18 +-
1 file changed, 17 insertions(+), 1 deletion(-)
LGTM!
Reviewed-by: Stefano Garzarella
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
