Al Viro said:
"""
Since "vhost/scsi: fix reuse of >iov[out] in response"
we have this:
cmd->tvc_resp_iov = vq->iov[vc.out];
cmd->tvc_in_iovs = vc.in;
combined with
iov_iter_init(_iter, ITER_DEST, >tvc_resp_iov,
tree/branch:
https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git master
branch HEAD: f3381a7baf5ccbd091eb2c4fd2afd84266fcef24 Add linux-next specific
files for 20230118
Error/Warning reports:
https://lore.kernel.org/oe-kbuild-all/202301171511.4zszviyp-...@intel.com
Error
On Thu, Jan 19, 2023 at 12:44 AM Eugenio Pérez wrote:
>
> vdpasim_queue_ready calls vringh_init_iotlb, which resets split indexes.
> But it can be called after setting a ring base with
> vdpasim_set_vq_state.
>
> Fix it by stashing them. They're still resetted in vdpasim_vq_reset.
>
> This was
> From: Jason Gunthorpe
> Sent: Thursday, January 19, 2023 2:01 AM
>
> There is only one call site and it can now just pass the GFP_ATOMIC to the
> normal iommu_map().
>
> Signed-off-by: Jason Gunthorpe
Reviewed-by: Kevin Tian
___
Virtualization
> From: Jason Gunthorpe
> Sent: Thursday, January 19, 2023 2:01 AM
>
> The internal mechanisms support this, but instead of exposting the gfp to
> the caller it wrappers it into iommu_map() and iommu_map_atomic()
>
> Fix this instead of adding more variants for GFP_KERNEL_ACCOUNT.
>
>
> From: Jason Gunthorpe
> Sent: Thursday, January 19, 2023 2:01 AM
>
> Follow the pattern for iommu_map() and remove iommu_map_sg_atomic().
>
> This allows __iommu_dma_alloc_noncontiguous() to use a GFP_KERNEL
> allocation here, based on the provided gfp flags.
>
> Signed-off-by: Jason
> From: Jason Gunthorpe
> Sent: Thursday, January 19, 2023 2:01 AM
>
> Flow it down to alloc_pgtable_page() via pfn_to_dma_pte() and
> __domain_mapping().
>
> Signed-off-by: Jason Gunthorpe
Reviewed-by: Kevin Tian
___
Virtualization mailing list
On Thu, Jan 19, 2023 at 12:44 AM Eugenio Pérez wrote:
>
> Starting from an used_idx different than 0 is needed in use cases like
> virtual machine migration. Not doing so and letting the caller set an
> avail idx different than 0 causes destination device to try to use old
> buffers that source
> From: Jason Gunthorpe
> Sent: Thursday, January 19, 2023 2:01 AM
>
> Change the sg_alloc_table_from_pages() allocation that was hardwired to
> GFP_KERNEL to use the gfp parameter like the other allocations in this
> function.
>
> Auditing says this is never called from an atomic context, so
> From: Jason Gunthorpe
> Sent: Thursday, January 19, 2023 2:01 AM
>
> iommufd follows the same design as KVM and uses memory cgroups to limit
> the amount of kernel memory a iommufd file descriptor can pin down. The
> various internal data structures already use GFP_KERNEL_ACCOUNT.
>
>
> From: Jason Gunthorpe
> Sent: Thursday, January 19, 2023 2:01 AM
>
> This is eventually called by iommufd through intel_iommu_map_pages() and
> it should not be forced to atomic. Push the GFP_ATOMIC to all callers.
>
> Signed-off-by: Jason Gunthorpe
Reviewed-by: Kevin Tian
> From: Jason Gunthorpe
> Sent: Thursday, January 19, 2023 2:01 AM
>
> These contexts are sleepable, so use the proper annotation. The
> GFP_ATOMIC
> was added mechanically in the prior patches.
>
> Signed-off-by: Jason Gunthorpe
Reviewed-by: Kevin Tian
This patch implements per virtqueue dma device for mlx5_vdpa. This is
needed for virtio_vdpa to work for CVQ which is backed by vringh but
not DMA. We simply advertise the vDPA device itself as the DMA device
for CVQ then DMA API can simply use PA so the identical mapping for
CVQ can still be
This patch introduces a new method to query the dma device that is use
for a specific virtqueue.
Reviewed-by: Eli Cohen
Tested-by: Eli Cohen
Signed-off-by: Jason Wang
---
include/linux/vdpa.h | 6 ++
1 file changed, 6 insertions(+)
diff --git a/include/linux/vdpa.h b/include/linux/vdpa.h
This patch adds the support of per vq dma device for virito-vDPA. vDPA
parents then are allowed to use different DMA devices. This is useful
for the parents that have software or emulated virtqueues.
Reviewed-by: Eli Cohen
Tested-by: Eli Cohen
Signed-off-by: Jason Wang
---
Hi All:
In some cases, the virtqueue could be backed by different devices. One
example is that in the case of vDPA some parent may emualte virtqueue
via vringh. In this case, it would be wrong if we stick with the
physical DMA device for software emulated device, since there's no
easy way for
This patch introduces a per virtqueue dma device. This will be used
for virtio devices whose virtqueue are backed by different underlayer
devices.
One example is the vDPA that where the control virtqueue could be
implemented through software mediation.
Some of the work are actually done before
Setting DMA mask for vDPA device in case that there are virtqueue that
is not backed by DMA so the vDPA device could be advertised as the DMA
device that is used by DMA API for software emulated virtqueues.
Reviewed-by: Eli Cohen
Tested-by: Eli Cohen
Signed-off-by: Jason Wang
---
18 matches
Mail list logo
