Re: [PATCH V2 vfio 5/9] virtio-pci: Initialize the supported admin commands
Hi Yishai,
kernel test robot noticed the following build warnings:
[auto build test WARNING on awilliam-vfio/for-linus]
[also build test WARNING on linus/master v6.6]
[cannot apply to awilliam-vfio/next mst-vhost/linux-next next-20231102]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch#_base_tree_information]
url:
https://github.com/intel-lab-lkp/linux/commits/Yishai-Hadas/virtio-Define-feature-bit-for-administration-virtqueue/20231030-000414
base: https://github.com/awilliam/linux-vfio.git for-linus
patch link:
https://lore.kernel.org/r/20231029155952.67686-6-yishaih%40nvidia.com
patch subject: [PATCH V2 vfio 5/9] virtio-pci: Initialize the supported admin
commands
config: i386-randconfig-061-20231102
(https://download.01.org/0day-ci/archive/20231103/202311030838.gjyabtjm-...@intel.com/config)
compiler: gcc-7 (Ubuntu 7.5.0-6ubuntu2) 7.5.0
reproduce (this is a W=1 build):
(https://download.01.org/0day-ci/archive/20231103/202311030838.gjyabtjm-...@intel.com/reproduce)
If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot
| Closes:
https://lore.kernel.org/oe-kbuild-all/202311030838.gjyabtjm-...@intel.com/
sparse warnings: (new ones prefixed by >>)
>> drivers/virtio/virtio_pci_modern.c:726:16: sparse: sparse: restricted __le16
>> degrades to integer
vim +726 drivers/virtio/virtio_pci_modern.c
673
674 static int vp_modern_admin_cmd_exec(struct virtio_device *vdev,
675 struct virtio_admin_cmd *cmd)
676 {
677 struct scatterlist *sgs[VIRTIO_AVQ_SGS_MAX], hdr, stat;
678 struct virtio_pci_device *vp_dev = to_vp_device(vdev);
679 struct virtio_admin_cmd_status *va_status;
680 unsigned int out_num = 0, in_num = 0;
681 struct virtio_admin_cmd_hdr *va_hdr;
682 struct virtqueue *avq;
683 u16 status;
684 int ret;
685
686 avq = virtio_has_feature(vdev, VIRTIO_F_ADMIN_VQ) ?
687 vp_dev->admin_vq.info.vq : NULL;
688 if (!avq)
689 return -EOPNOTSUPP;
690
691 va_status = kzalloc(sizeof(*va_status), GFP_KERNEL);
692 if (!va_status)
693 return -ENOMEM;
694
695 va_hdr = kzalloc(sizeof(*va_hdr), GFP_KERNEL);
696 if (!va_hdr) {
697 ret = -ENOMEM;
698 goto err_alloc;
699 }
700
701 va_hdr->opcode = cmd->opcode;
702 va_hdr->group_type = cmd->group_type;
703 va_hdr->group_member_id = cmd->group_member_id;
704
705 /* Add header */
706 sg_init_one(, va_hdr, sizeof(*va_hdr));
707 sgs[out_num] =
708 out_num++;
709
710 if (cmd->data_sg) {
711 sgs[out_num] = cmd->data_sg;
712 out_num++;
713 }
714
715 /* Add return status */
716 sg_init_one(, va_status, sizeof(*va_status));
717 sgs[out_num + in_num] =
718 in_num++;
719
720 if (cmd->result_sg) {
721 sgs[out_num + in_num] = cmd->result_sg;
722 in_num++;
723 }
724
725 if (cmd->opcode == VIRTIO_ADMIN_CMD_LIST_QUERY ||
> 726 cmd->opcode == VIRTIO_ADMIN_CMD_LIST_USE)
727 ret = __virtqueue_exec_admin_cmd(_dev->admin_vq, sgs,
728 out_num, in_num,
729 sgs, GFP_KERNEL);
730 else
731 ret = virtqueue_exec_admin_cmd(_dev->admin_vq, sgs,
732 out_num, in_num,
733 sgs, GFP_KERNEL);
734 if (ret) {
735 dev_err(>dev,
736 "Failed to execute command on admin vq: %d\n.",
ret);
737 goto err_cmd_exec;
738 }
739
740 status = le16_to_cpu(va_status->status);
741 if (status != VIRTIO_ADMIN_STATUS_OK) {
742 dev_err(>dev,
743 "admin command error: status(%#x)
qualifier(%#x)\n",
744 status,
le16_to_cpu(va_status->status_qualifier));
745 ret = -status;
746 }
747
748 err_cmd_exec:
749 kfree(va_hdr);
750 err_alloc:
751 kfree(va_status);
752 return ret;
753 }
754
--
0-DAY CI Kernel Test Service
https://gith
Re: [PATCH v4 4/4] vduse: Add LSM hooks to check Virtio device type
On Thu, Nov 02, 2023 at 06:56:59PM +0100, Maxime Coquelin wrote: > > > On 10/24/23 17:30, Casey Schaufler wrote: > > On 10/24/2023 2:49 AM, Maxime Coquelin wrote: > > > > > > > > > On 10/23/23 17:13, Casey Schaufler wrote: > > > > On 10/23/2023 12:28 AM, Maxime Coquelin wrote: > > > > > > > > > > > > > > > On 10/21/23 00:20, Casey Schaufler wrote: > > > > > > On 10/20/2023 8:58 AM, Maxime Coquelin wrote: > > > > > > > This patch introduces LSM hooks for devices creation, > > > > > > > destruction and opening operations, checking the > > > > > > > application is allowed to perform these operations for > > > > > > > the Virtio device type. > > > > > > > > > > > > Why do you think that there needs to be a special LSM check for > > > > > > virtio > > > > > > devices? What can't existing device attributes be used? > > > > > > > > > > Michael asked for a way for SELinux to allow/prevent the creation of > > > > > some types of devices [0]. > > > > > > > > > > A device is created using ioctl() on VDUSE control chardev. Its type > > > > > is > > > > > specified via a field in the structure passed in argument. > > > > > > > > > > I didn't see other way than adding dedicated LSM hooks to achieve > > > > > this, > > > > > but it is possible that their is a better way to do it? > > > > > > > > At the very least the hook should be made more general, and I'd have to > > > > see a proposal before commenting on that. security_dev_destroy(dev) > > > > might > > > > be a better approach. If there's reason to control destruction of vduse > > > > devices it's reasonable to assume that there are other devices with the > > > > same or similar properties. > > > > > > VDUSE is different from other devices as the device is actually > > > implemented by the user-space application, so this is very specific in > > > my opinion. > > > > This is hardly unique. If you're implementing the device > > in user-space you may well be able to implement the desired > > controls there. > > > > > > > > > > > > > Since SELinux is your target use case, can you explain why you can't > > > > create SELinux policy to enforce the restrictions you're after? I > > > > believe > > > > (but can be proven wrong, of course) that SELinux has mechanism for > > > > dealing > > > > with controls on ioctls. > > > > > > > > > > I am not aware of such mechanism to deal with ioctl(), if you have a > > > pointer that would be welcome. > > > > security/selinux/hooks.c > > We might be able to extend selinux_file_ioctl(), but that will only > covers the ioctl for the control file, this patch also adds hook for the > device file opening that would need dedicated hook as the device type > information is stored in the device's private data. > > Michael, before going further, I would be interested in your feedback. > Was this patch what you had in mind when requesting for a way to > allow/deny devices types for a given application? > > Regards, > Maxime Yes, this is more or less what I had in mind. > > > > > > > > Thanks, > > > Maxime > > > > > > > > > > > > > > > > > Thanks, > > > > > Maxime > > > > > > > > > > [0]: > > > > > https://lore.kernel.org/all/20230829130430-mutt-send-email-...@kernel.org/ > > > > > > > > > > > > > > > > > > > ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/virtualization
Re: [PATCH v4 4/4] vduse: Add LSM hooks to check Virtio device type
On 10/24/23 17:30, Casey Schaufler wrote: On 10/24/2023 2:49 AM, Maxime Coquelin wrote: On 10/23/23 17:13, Casey Schaufler wrote: On 10/23/2023 12:28 AM, Maxime Coquelin wrote: On 10/21/23 00:20, Casey Schaufler wrote: On 10/20/2023 8:58 AM, Maxime Coquelin wrote: This patch introduces LSM hooks for devices creation, destruction and opening operations, checking the application is allowed to perform these operations for the Virtio device type. Why do you think that there needs to be a special LSM check for virtio devices? What can't existing device attributes be used? Michael asked for a way for SELinux to allow/prevent the creation of some types of devices [0]. A device is created using ioctl() on VDUSE control chardev. Its type is specified via a field in the structure passed in argument. I didn't see other way than adding dedicated LSM hooks to achieve this, but it is possible that their is a better way to do it? At the very least the hook should be made more general, and I'd have to see a proposal before commenting on that. security_dev_destroy(dev) might be a better approach. If there's reason to control destruction of vduse devices it's reasonable to assume that there are other devices with the same or similar properties. VDUSE is different from other devices as the device is actually implemented by the user-space application, so this is very specific in my opinion. This is hardly unique. If you're implementing the device in user-space you may well be able to implement the desired controls there. Since SELinux is your target use case, can you explain why you can't create SELinux policy to enforce the restrictions you're after? I believe (but can be proven wrong, of course) that SELinux has mechanism for dealing with controls on ioctls. I am not aware of such mechanism to deal with ioctl(), if you have a pointer that would be welcome. security/selinux/hooks.c We might be able to extend selinux_file_ioctl(), but that will only covers the ioctl for the control file, this patch also adds hook for the device file opening that would need dedicated hook as the device type information is stored in the device's private data. Michael, before going further, I would be interested in your feedback. Was this patch what you had in mind when requesting for a way to allow/deny devices types for a given application? Regards, Maxime Thanks, Maxime Thanks, Maxime [0]: https://lore.kernel.org/all/20230829130430-mutt-send-email-...@kernel.org/ ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/virtualization
RE: virtcrypto_dataq_callback calls crypto_finalize_request() from irq context
> -Original Message- > From: Michael S. Tsirkin [mailto:m...@redhat.com] > Sent: Thursday, November 2, 2023 9:17 PM > To: Gonglei (Arei) > Cc: Halil Pasic ; Herbert Xu > ; Jason Wang ; > virtualization@lists.linux-foundation.org; linux-ker...@vger.kernel.org; > linux-cry...@vger.kernel.org; Marc Hartmayer > Subject: Re: virtcrypto_dataq_callback calls crypto_finalize_request() from > irq > context > > On Thu, Nov 02, 2023 at 01:04:07PM +, Gonglei (Arei) wrote: > > > > > > > -Original Message- > > > From: Michael S. Tsirkin [mailto:m...@redhat.com] > > > Sent: Wednesday, November 1, 2023 9:26 PM > > > To: Halil Pasic > > > Cc: Gonglei (Arei) ; Herbert Xu > > > ; Jason Wang ; > > > virtualization@lists.linux-foundation.org; > > > linux-ker...@vger.kernel.org; linux-cry...@vger.kernel.org; Marc > > > Hartmayer > > > Subject: Re: virtcrypto_dataq_callback calls > > > crypto_finalize_request() from irq context > > > > > > On Sun, Sep 24, 2023 at 07:39:41PM +0200, Halil Pasic wrote: > > > > On Sun, 24 Sep 2023 11:56:25 + "Gonglei (Arei)" > > > > wrote: > > > > > > > > > Hi Halil, > > > > > > > > > > Commit 4058cf08945 introduced a check for detecting crypto > > > > > completion function called with enable BH, and indeed the > > > > > virtio-crypto driver didn't disable BH, which needs a patch to fix it. > > > > > > > > > > P.S.: > > > > > https://lore.kernel.org/lkml/20220221120833.2618733-5-clabbe@bay > > > > > libr > > > > > e.com/T/ > > > > > > > > > > Regards, > > > > > -Gonglei > > > > > > > > Thanks Gonglei! > > > > > > > > Thanks! I would be glad to test that fix on s390x. Are you about > > > > to send one? > > > > > > > > Regards, > > > > Halil > > > > > > > > > Gonglei did you intend to send a fix? > > > > Actually I sent a patch a month ago, pls see another thread. > > > > > > Regards, > > -Gonglei > > And I think there was an issue with that patch that you wanted to fix? > config changed callback got fixed but this still didn't. > Now my concern is whether or not the judgement (commit 4058cf08945c1) is reasonable. Regards, -Gonglei ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/virtualization
RE: virtcrypto_dataq_callback calls crypto_finalize_request() from irq context
> -Original Message- > From: Michael S. Tsirkin [mailto:m...@redhat.com] > Sent: Wednesday, November 1, 2023 9:26 PM > To: Halil Pasic > Cc: Gonglei (Arei) ; Herbert Xu > ; Jason Wang ; > virtualization@lists.linux-foundation.org; linux-ker...@vger.kernel.org; > linux-cry...@vger.kernel.org; Marc Hartmayer > Subject: Re: virtcrypto_dataq_callback calls crypto_finalize_request() from > irq > context > > On Sun, Sep 24, 2023 at 07:39:41PM +0200, Halil Pasic wrote: > > On Sun, 24 Sep 2023 11:56:25 + > > "Gonglei (Arei)" wrote: > > > > > Hi Halil, > > > > > > Commit 4058cf08945 introduced a check for detecting crypto > > > completion function called with enable BH, and indeed the > > > virtio-crypto driver didn't disable BH, which needs a patch to fix it. > > > > > > P.S.: > > > https://lore.kernel.org/lkml/20220221120833.2618733-5-clabbe@baylibr > > > e.com/T/ > > > > > > Regards, > > > -Gonglei > > > > Thanks Gonglei! > > > > Thanks! I would be glad to test that fix on s390x. Are you about to > > send one? > > > > Regards, > > Halil > > > Gonglei did you intend to send a fix? Actually I sent a patch a month ago, pls see another thread. Regards, -Gonglei ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/virtualization
RE: [PATCH] crypto: virtio-crypto: call finalize with bh disabled
Ping Herbert.
Thanks.
> -Original Message-
> From: Gonglei (Arei)
> Sent: Wednesday, September 27, 2023 5:18 PM
> To: 'Halil Pasic'
> Cc: Herbert Xu ; linux-cry...@vger.kernel.org;
> Marc Hartmayer ; Michael S. Tsirkin
> ; Jason Wang ;
> virtualization@lists.linux-foundation.org; linux-ker...@vger.kernel.org;
> pizhen...@bytedance.com; Cornelia Huck
> Subject: RE: [PATCH] crypto: virtio-crypto: call finalize with bh disabled
>
>
>
> > -Original Message-
> > From: Halil Pasic [mailto:pa...@linux.ibm.com]
> > Sent: Wednesday, September 27, 2023 12:42 AM
> > To: Gonglei (Arei)
> > Cc: Herbert Xu ;
> > linux-cry...@vger.kernel.org; Marc Hartmayer ;
> > Michael S. Tsirkin ; Jason Wang
> ;
> > virtualization@lists.linux-foundation.org;
> > linux-ker...@vger.kernel.org; pizhen...@bytedance.com; Halil Pasic
> > ; Cornelia Huck
> > Subject: Re: [PATCH] crypto: virtio-crypto: call finalize with bh
> > disabled
> >
> > [..]
> > > --- a/drivers/crypto/virtio/virtio_crypto_akcipher_algs.c
> > > +++ b/drivers/crypto/virtio/virtio_crypto_akcipher_algs.c
> > > @@ -61,8 +61,9 @@ static void virtio_crypto_akcipher_finalize_req(
> > > vc_akcipher_req->src_buf = NULL;
> > > vc_akcipher_req->dst_buf = NULL;
> > > virtcrypto_clear_request(_akcipher_req->base);
> > > -
> > > + local_bh_disable();
> > >
> > > crypto_finalize_akcipher_request(vc_akcipher_req->base.dataq->engine
> > > ,
> > > req, err);
> > > + local_bh_enable();
> >
> > Thanks Gonglei!
> >
> > I did this a quick spin, and it does not seem to be sufficient on s390x.
> > Which does not come as a surprise to me, because
> >
> > #define lockdep_assert_in_softirq()
> > \
> > do
> > {
> > \
> > WARN_ON_ONCE(__lockdep_enabled &&
> > \
> > (!in_softirq() || in_irq() || in_nmi())); \
> > } while (0)
> >
> > will still warn because in_irq() still evaluates to true (your patch
> > addresses the !in_softirq() part).
> >
> You are right.
>
> So I think the core of this question is: Can we call
> crypto_finalize_request() in
> the upper half of the interrupt?
> If so, maybe we should introduce a new function, such as
> lockdep_assert_in_interrupt().
>
> #define lockdep_assert_in_interrupt() \
> do { \
>WARN_ON_ONCE(__lockdep_enabled && !in_interrupt());\
> } while (0)
>
> If not, why?
>
> Herbert, do you have any suggestions? Thanks.
>
>
> Regards,
> -Gonglei
>
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
Re: virtcrypto_dataq_callback calls crypto_finalize_request() from irq context
On Thu, Nov 02, 2023 at 01:04:07PM +, Gonglei (Arei) wrote: > > > > -Original Message- > > From: Michael S. Tsirkin [mailto:m...@redhat.com] > > Sent: Wednesday, November 1, 2023 9:26 PM > > To: Halil Pasic > > Cc: Gonglei (Arei) ; Herbert Xu > > ; Jason Wang ; > > virtualization@lists.linux-foundation.org; linux-ker...@vger.kernel.org; > > linux-cry...@vger.kernel.org; Marc Hartmayer > > Subject: Re: virtcrypto_dataq_callback calls crypto_finalize_request() from > > irq > > context > > > > On Sun, Sep 24, 2023 at 07:39:41PM +0200, Halil Pasic wrote: > > > On Sun, 24 Sep 2023 11:56:25 + > > > "Gonglei (Arei)" wrote: > > > > > > > Hi Halil, > > > > > > > > Commit 4058cf08945 introduced a check for detecting crypto > > > > completion function called with enable BH, and indeed the > > > > virtio-crypto driver didn't disable BH, which needs a patch to fix it. > > > > > > > > P.S.: > > > > https://lore.kernel.org/lkml/20220221120833.2618733-5-clabbe@baylibr > > > > e.com/T/ > > > > > > > > Regards, > > > > -Gonglei > > > > > > Thanks Gonglei! > > > > > > Thanks! I would be glad to test that fix on s390x. Are you about to > > > send one? > > > > > > Regards, > > > Halil > > > > > > Gonglei did you intend to send a fix? > > Actually I sent a patch a month ago, pls see another thread. > > > Regards, > -Gonglei And I think there was an issue with that patch that you wanted to fix? config changed callback got fixed but this still didn't. -- MST ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/virtualization
Re: [PATCH v2 0/6] IOMMUFD: Deliver IO page faults to user space
On Thu, Oct 26, 2023 at 10:49:24AM +0800, Lu Baolu wrote: > Hi folks, > > This series implements the functionality of delivering IO page faults to > user space through the IOMMUFD framework for nested translation. Nested > translation is a hardware feature that supports two-stage translation > tables for IOMMU. The second-stage translation table is managed by the > host VMM, while the first-stage translation table is owned by user > space. This allows user space to control the IOMMU mappings for its > devices. Having now looked more closely at the ARM requirements it seems we will need generic events, not just page fault events to have a complete emulation. So I'd like to see this generalized into a channel to carry any events.. > User space indicates its capability of handling IO page faults by > setting the IOMMU_HWPT_ALLOC_IOPF_CAPABLE flag when allocating a > hardware page table (HWPT). IOMMUFD will then set up its infrastructure > for page fault delivery. On a successful return of HWPT allocation, the > user can retrieve and respond to page faults by reading and writing to > the file descriptor (FD) returned in out_fault_fd. This is the right way to approach it, and more broadly this shouldn't be an iommufd specific thing. Kernel drivers will also need to create fault capable PAGING iommu domains. Jason ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/virtualization
Re: [RFC 0/7] vdpa: Add support for iommufd
On Thu, Oct 26, 2023 at 02:48:07PM +0800, Cindy Lu wrote: > On Thu, Oct 26, 2023 at 2:42 PM Michael S. Tsirkin wrote: > > > > On Sun, Sep 24, 2023 at 01:05:33AM +0800, Cindy Lu wrote: > > > Hi All > > > Really apologize for the delay, this is the draft RFC for > > > iommufd support for vdpa, This code provides the basic function > > > for iommufd support > > > > > > The code was tested and passed in device vdpa_sim_net > > > The qemu code is > > > https://gitlab.com/lulu6/gitlabqemutmp/-/tree/iommufdRFC > > > The kernel code is > > > https://gitlab.com/lulu6/vhost/-/tree/iommufdRFC > > > > > > ToDo > > > 1. this code is out of date and needs to clean and rebase on the latest > > > code > > > 2. this code has some workaround, I Skip the check for > > > iommu_group and CACHE_COHERENCY, also some misc issues like need to add > > > mutex for iommfd operations > > > 3. only test in emulated device, other modes not tested yet > > > > > > After addressed these problems I will send out a new version for RFC. I > > > will > > > provide the code in 3 weeks > > > > What's the status here? > > > Hi Michael > The code is finished, but I found some bug after adding the support for ASID, > will post the new version after this bug is fixed, should be next week > Thanks > Cindy The week is almost gone, what's going on? > > -- > > MST > > ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/virtualization
Re: [PATCH V2] vdpa/mlx5: preserve CVQ vringh index
On Thu, Nov 2, 2023 at 3:10 PM Eugenio Perez Martin wrote:
>
> On Wed, Nov 1, 2023 at 4:55 PM Steve Sistare
> wrote:
> >
> > mlx5_vdpa does not preserve userland's view of vring base for the control
> > queue in the following sequence:
> >
> > ioctl VHOST_SET_VRING_BASE
> > ioctl VHOST_VDPA_SET_STATUS VIRTIO_CONFIG_S_DRIVER_OK
> > mlx5_vdpa_set_status()
> > setup_cvq_vring()
> > vringh_init_iotlb()
> > vringh_init_kern()
> > vrh->last_avail_idx = 0;
> > ioctl VHOST_GET_VRING_BASE
> >
> > To fix, restore the value of cvq->vring.last_avail_idx after calling
> > vringh_init_iotlb.
> >
>
> Fixes tag missing?
+1
>
> Apart from that,
>
> Acked-by: Eugenio Pérez
With the fix tag added.
Acked-by: Jason Wang
Thanks
>
> > Signed-off-by: Steve Sistare
> > ---
> > drivers/vdpa/mlx5/net/mlx5_vnet.c | 7 ++-
> > 1 file changed, 6 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/vdpa/mlx5/net/mlx5_vnet.c
> > b/drivers/vdpa/mlx5/net/mlx5_vnet.c
> > index 946488b8989f..ca972af3c89a 100644
> > --- a/drivers/vdpa/mlx5/net/mlx5_vnet.c
> > +++ b/drivers/vdpa/mlx5/net/mlx5_vnet.c
> > @@ -2795,13 +2795,18 @@ static int setup_cvq_vring(struct mlx5_vdpa_dev
> > *mvdev)
> > struct mlx5_control_vq *cvq = >cvq;
> > int err = 0;
> >
> > - if (mvdev->actual_features & BIT_ULL(VIRTIO_NET_F_CTRL_VQ))
> > + if (mvdev->actual_features & BIT_ULL(VIRTIO_NET_F_CTRL_VQ)) {
> > + u16 idx = cvq->vring.last_avail_idx;
> > +
> > err = vringh_init_iotlb(>vring, mvdev->actual_features,
> > MLX5_CVQ_MAX_ENT, false,
> > (struct vring_desc
> > *)(uintptr_t)cvq->desc_addr,
> > (struct vring_avail
> > *)(uintptr_t)cvq->driver_addr,
> > (struct vring_used
> > *)(uintptr_t)cvq->device_addr);
> >
> > + if (!err)
> > + cvq->vring.last_avail_idx =
> > cvq->vring.last_used_idx = idx;
> > + }
> > return err;
> > }
> >
> > --
> > 2.39.3
> >
>
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
