On Wed, Apr 23, 2025 at 08:13:33PM -0300, Jason Gunthorpe wrote:
> On Wed, Apr 23, 2025 at 11:31:29AM -0700, Nicolin Chen wrote:
>
> > > It also needs to act like a mdev and lock down the part of the IOAS
> > > that provides that memory so the pin can't be released and UAF things.
> >
> > If I ca
On Thu, Apr 10, 2025 at 11:45:58AM +0200, Radim Krčmář wrote:
2025-03-14T14:39:31-07:00, Deepak Gupta :
diff --git a/arch/riscv/include/asm/usercfi.h b/arch/riscv/include/asm/usercfi.h
@@ -14,7 +15,8 @@ struct kernel_clone_args;
struct cfi_status {
unsigned long ubcfi_en : 1; /* Enable
v11:
https://lore.kernel.org/netdev/20250423031117.907681-1-almasrym...@google.com/
Addressed a couple of nits and collected Acked-by from Harshitha
(thanks!)
v10:
https://lore.kernel.org/netdev/20250417231540.2780723-1-almasrym...@google.com/
Addressed comments following conversations with Pa
Add documentation outlining the usage and details of the devmem TCP TX
API.
Signed-off-by: Mina Almasry
Acked-by: Stanislav Fomichev
---
v5:
- Address comments from Stan and Bagas
v4:
- Mention SO_BINDTODEVICE is recommended (me/Pavel).
v2:
- Update documentation for iov_base is the dmabuf o
Use netmem_dma_*() helpers in gve_tx_dqo.c DQO-RDA paths to
enable netmem TX support in that mode.
Declare support for netmem TX in GVE DQO-RDA mode.
Signed-off-by: Mina Almasry
Acked-by: Harshitha Ramamurthy
---
v11:
- Fix whitespace (Harshitha)
v10:
- Move setting dev->netmem_tx to right a
We should not enable netmem TX for drivers that don't declare support.
Check for driver netmem TX support during devmem TX binding and fail if
the driver does not have the functionality.
Check for driver support in validate_xmit_skb as well.
Signed-off-by: Mina Almasry
Acked-by: Stanislav Fomic
Augment dmabuf binding to be able to handle TX. Additional to all the RX
binding, we also create tx_vec needed for the TX path.
Provide API for sendmsg to be able to send dmabufs bound to this device:
- Provide a new dmabuf_tx_cmsg which includes the dmabuf to send from.
- MSG_ZEROCOPY with SCM_D
Drivers need to make sure not to pass netmem dma-addrs to the
dma-mapping API in order to support netmem TX.
Add helpers and netmem_dma_*() helpers that enables special handling of
netmem dma-addrs that drivers can use.
Document in netmem.rst what drivers need to do to support netmem TX.
Signed-
From: Stanislav Fomichev
Add bind-tx netlink call to attach dmabuf for TX; queue is not
required, only ifindex and dmabuf fd for attachment.
Signed-off-by: Stanislav Fomichev
Signed-off-by: Mina Almasry
---
v3:
- Fix ynl-regen.sh error (Simon).
---
Documentation/netlink/specs/netdev.yaml |
Currently net_iovs support only pp ref counts, and do not support a
page ref equivalent.
This is fine for the RX path as net_iovs are used exclusively with the
pp and only pp refcounting is needed there. The TX path however does not
use pp ref counts, thus, support for get_page/put_page equivalent
Later patches in the series adds TX net_iovs where there is no pp
associated, so we can't rely on niov->pp->mp_ops to tell what is the
type of the net_iov.
Add a type enum to the net_iov which tells us the net_iov type.
Signed-off-by: Mina Almasry
---
v8:
- Since io_uring zcrx is now in net-ne
On Thu, Apr 10, 2025 at 11:56:44AM +0200, Radim Krčmář wrote:
2025-03-14T14:39:29-07:00, Deepak Gupta :
As discussed extensively in the changelog for the addition of this
syscall on x86 ("x86/shstk: Introduce map_shadow_stack syscall") the
existing mmap() and madvise() syscalls do not map entire
On Thu, Apr 10, 2025 at 12:03:44PM +0200, Radim Krčmář wrote:
2025-03-14T14:39:25-07:00, Deepak Gupta :
diff --git a/arch/riscv/include/asm/mman.h b/arch/riscv/include/asm/mman.h
+static inline unsigned long arch_calc_vm_prot_bits(unsigned long prot,
+
Sorry forgot to respond to rest of your comments on this thread.
On Thu, Apr 10, 2025 at 01:04:39PM +0200, Radim Krčmář wrote:
2025-03-14T14:39:24-07:00, Deepak Gupta :
diff --git a/arch/riscv/include/asm/thread_info.h
b/arch/riscv/include/asm/thread_info.h
@@ -62,6 +62,9 @@ struct thread_inf
On Thu, Apr 10, 2025 at 01:04:39PM +0200, Radim Krčmář wrote:
2025-03-14T14:39:24-07:00, Deepak Gupta :
diff --git a/arch/riscv/include/asm/thread_info.h
b/arch/riscv/include/asm/thread_info.h
@@ -62,6 +62,9 @@ struct thread_info {
longuser_sp;/* User stack p
On Wed, Apr 23, 2025 at 11:24 AM Michael S. Tsirkin wrote:
>
> some nits
>
> On Wed, Apr 23, 2025 at 03:11:11AM +, Mina Almasry wrote:
> > @@ -189,43 +200,44 @@ net_devmem_bind_dmabuf(struct net_device *dev,
> > unsigned int dmabuf_fd,
> > }
> >
> > binding->dev = dev;
> > -
> > -
On Wed, Apr 23, 2025 at 11:31:29AM -0700, Nicolin Chen wrote:
> > It also needs to act like a mdev and lock down the part of the IOAS
> > that provides that memory so the pin can't be released and UAF things.
>
> If I capture this correctly, the GPA->PA mapping is already done
> at the IOAS level
On 25/04/22 06:36PM, Joanne Koong wrote:
> On Sun, Apr 20, 2025 at 6:34 PM John Groves wrote:
> >
> > * FUSE_DAX_FMAP flag in INIT request/reply
> >
> > * fuse_conn->famfs_iomap (enable famfs-mapped files) to denote a
> > famfs-enabled connection
> >
> > Signed-off-by: John Groves
> > ---
> >
On 25/04/22 06:51PM, Joanne Koong wrote:
> On Sun, Apr 20, 2025 at 6:34 PM John Groves wrote:
> >
> > * -o shadow=
> > * -o daxdev=
> >
> > Signed-off-by: John Groves
> > ---
> > fs/fuse/fuse_i.h | 8 +++-
> > fs/fuse/inode.c | 25 -
> > 2 files changed, 31 insertio
On Wed, Apr 23, 2025 at 08:55:51AM -0300, Jason Gunthorpe wrote:
> On Wed, Apr 23, 2025 at 08:05:49AM +, Tian, Kevin wrote:
>
> > It's not a good idea having the kernel trust the VMM.
>
> It certainly shouldn't trust it, but it can validate the VMM's choice
> and generate a failure if it isn
On Tue, Apr 22, 2025 at 8:11 PM Mina Almasry wrote:
>
> Use netmem_dma_*() helpers in gve_tx_dqo.c DQO-RDA paths to
> enable netmem TX support in that mode.
>
> Declare support for netmem TX in GVE DQO-RDA mode.
>
> Signed-off-by: Mina Almasry
>
> ---
>
> v10:
> - Move setting dev->netmem_tx to r
some nits
On Wed, Apr 23, 2025 at 03:11:11AM +, Mina Almasry wrote:
> @@ -189,43 +200,44 @@ net_devmem_bind_dmabuf(struct net_device *dev, unsigned
> int dmabuf_fd,
> }
>
> binding->dev = dev;
> -
> - err = xa_alloc_cyclic(&net_devmem_dmabuf_bindings, &binding->id,
> -
On Wed, Apr 23, 2025 at 5:11 AM Donald Hunter wrote:
>
> Mina Almasry writes:
>
> > From: Stanislav Fomichev
> >
> > Add bind-tx netlink call to attach dmabuf for TX; queue is not
> > required, only ifindex and dmabuf fd for attachment.
> >
> > Signed-off-by: Stanislav Fomichev
> > Signed-off-b
On Thu, Apr 10, 2025 at 11:37:46PM -0700, Nicolin Chen wrote:
> To allow IOMMU drivers to allocate own vDEVICE structures, move the struct
> iommufd_vdevice to the public header and provide a pair of viommu ops.
>
> The iommufd_vdevice_alloc_ioctl will prioritize the callback function from
> the v
On Thu, Apr 10, 2025 at 11:37:43PM -0700, Nicolin Chen wrote:
> An IOMMU driver that allocated a vIOMMU may want to revert the allocation,
> if it encounters an internal error after the allocation. So, there needs a
> destroy helper for drivers to use.
>
> Move iommufd_object_abort() to the driver
On Thu, Apr 10, 2025 at 11:37:42PM -0700, Nicolin Chen wrote:
> Similar to the iommu_copy_struct_from_user helper receiving data from the
> user space, add an iommu_copy_struct_to_user helper to report output data
> back to the user space data pointer.
>
> Signed-off-by: Nicolin Chen
> ---
> inc
On Thu, Apr 10, 2025 at 11:37:41PM -0700, Nicolin Chen wrote:
> The new type of vIOMMU for tegra241-cmdqv driver needs a driver-specific
> user data. So, add data_len/uptr to the iommu_viommu_alloc uAPI and pass
> it in via the viommu_alloc iommu op.
>
> Signed-off-by: Nicolin Chen
> ---
> inclu
On Thu, Apr 10, 2025 at 11:37:40PM -0700, Nicolin Chen wrote:
> The new type of vIOMMU for tegra241-cmdqv needs to pass in a driver-level
> data structure from user space via iommufd, so add a user_data to the op.
>
> Signed-off-by: Nicolin Chen
> ---
> drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.
Mina Almasry writes:
> From: Stanislav Fomichev
>
> Add bind-tx netlink call to attach dmabuf for TX; queue is not
> required, only ifindex and dmabuf fd for attachment.
>
> Signed-off-by: Stanislav Fomichev
> Signed-off-by: Mina Almasry
>
> ---
>
> v3:
> - Fix ynl-regen.sh error (Simon).
>
>
On Wed, Apr 23, 2025 at 08:05:49AM +, Tian, Kevin wrote:
> It's not a good idea having the kernel trust the VMM.
It certainly shouldn't trust it, but it can validate the VMM's choice
and generate a failure if it isn't good.
> Also I'm not
> sure the contiguity is guaranteed all the time wit
* Arnaud POULIQUEN (arnaud.pouliq...@foss.st.com) wrote:
> Hello,
>
> On 4/20/25 22:41, li...@treblig.org wrote:
> > From: "Dr. David Alan Gilbert"
> >
> > rpmsg_send_offchannel() and rpmsg_trysend_offchannel() have been
> > unused since they were added in 2011's
> > commit bcabbccabffe ("rpmsg:
On 4/22/25 22:10, Mina Almasry wrote:
...
Instead of adding net_iov / devmem handling in generic paths affecting
everyone, you could change those functions where it's get_page() are
called legitimately. The niov/devmem part of get/put_netmem doesn't
even have the same semantics as the page counte
> From: Nicolin Chen
> Sent: Tuesday, April 22, 2025 3:14 AM
> On Mon, Apr 21, 2025 at 08:37:40AM +, Tian, Kevin wrote:
> > > From: Nicolin Chen
> > > Sent: Friday, April 11, 2025 2:38 PM
> > >
> > > +
> > > + vcmdq = iommufd_vcmdq_alloc(viommu, struct tegra241_vcmdq,
> > > core);
> > > + if
On Wed, Apr 23, 2025 at 12:58:19PM +0530, Vasant Hegde wrote:
> On 4/11/2025 12:07 PM, Nicolin Chen wrote:
> > The vIOMMU object is designed to represent a slice of an IOMMU HW for its
> > virtualization features shared with or passed to user space (a VM mostly)
> > in a way of HW acceleration. Thi
Hello,
On 4/20/25 22:41, li...@treblig.org wrote:
> From: "Dr. David Alan Gilbert"
>
> rpmsg_send_offchannel() and rpmsg_trysend_offchannel() have been
> unused since they were added in 2011's
> commit bcabbccabffe ("rpmsg: add virtio-based remote processor messaging
> bus")
>
> Remove them and
Hi Nicolin,
On 4/11/2025 12:07 PM, Nicolin Chen wrote:
> The vIOMMU object is designed to represent a slice of an IOMMU HW for its
> virtualization features shared with or passed to user space (a VM mostly)
> in a way of HW acceleration. This extended the HWPT-based design for more
> advanced vir
36 matches
Mail list logo
