On Wed, Sep 11, 2024 at 08:39:57PM -0700, Nicolin Chen wrote:
> You mentioned that actually only the iommufd selftest might hit such
> a corner case, so perhaps we should do something in the selftest code
> v.s. the iommu core. What do you think?
Maybe, if there were viommu allocation callbacks m
On Thu, Aug 22, 2024 at 01:24:25PM -0300, Jason Gunthorpe wrote:
> On Thu, Aug 22, 2024 at 10:17:56AM -0600, Mathieu Poirier wrote:
>
> > > - domain = iommu_domain_alloc(dev->bus);
> > > - if (!domain) {
> > > + domain = iommu_paging_domain_alloc(dev);
On Fri, Sep 13, 2024 at 02:33:59AM +, Tian, Kevin wrote:
> > From: Jason Gunthorpe
> > Sent: Thursday, September 12, 2024 7:08 AM
> >
> > On Wed, Sep 11, 2024 at 08:13:01AM +, Tian, Kevin wrote:
> >
> > > Probably there is a good reason e.g. for
On Thu, Sep 05, 2024 at 10:53:31AM -0700, Nicolin Chen wrote:
> On Thu, Sep 05, 2024 at 01:14:15PM -0300, Jason Gunthorpe wrote:
> > On Tue, Aug 27, 2024 at 09:59:47AM -0700, Nicolin Chen wrote:
> > > Driver can call the iommufd_viommu_find_device() to find a device pointer
&
On Wed, Sep 11, 2024 at 08:13:01AM +, Tian, Kevin wrote:
> Probably there is a good reason e.g. for simplification or better
> aligned with hw accel stuff. But it's not explained clearly so far.
Probably the most concrete thing is if you have a direct assignment
invalidation queue (ie DMA'd d
On Wed, Sep 11, 2024 at 06:25:16AM +, Tian, Kevin wrote:
> > From: Jason Gunthorpe
> > Sent: Friday, September 6, 2024 2:22 AM
> >
> > On Thu, Sep 05, 2024 at 11:00:49AM -0700, Nicolin Chen wrote:
> > > On Thu, Sep 05, 2024 at 01:20:39PM -0300, Jason Guntho
On Thu, Sep 05, 2024 at 11:00:49AM -0700, Nicolin Chen wrote:
> On Thu, Sep 05, 2024 at 01:20:39PM -0300, Jason Gunthorpe wrote:
> > On Tue, Aug 27, 2024 at 09:59:54AM -0700, Nicolin Chen wrote:
> >
> > > +static int arm_smmu_viommu_cache_invalidate(struct iommu
On Tue, Aug 27, 2024 at 10:02:06AM -0700, Nicolin Chen wrote:
> The iommufd core provides a lookup helper for an IOMMU driver to find a
> device pointer by device's per-viommu virtual ID. Yet a driver may need
> an inverted lookup to find a device's per-viommu virtual ID by a device
> pointer, e.g.
On Thu, Sep 05, 2024 at 10:10:38AM -0700, Nicolin Chen wrote:
> On Thu, Sep 05, 2024 at 12:53:02PM -0300, Jason Gunthorpe wrote:
> > On Tue, Aug 27, 2024 at 09:59:39AM -0700, Nicolin Chen wrote:
> > > +/**
> > > + * struct iommu_viommu_alloc - ioctl(IOMMU_VIOMMU_ALL
On Thu, Sep 05, 2024 at 10:37:45AM -0700, Nicolin Chen wrote:
> we only have virtual device ID in its data structure. Also, the
> virtual device sounds a bit confusing, given we already have idev.
idev is "iommufd device" which is the physical device
The virtual device is the host side handle of
On Tue, Aug 27, 2024 at 09:59:53AM -0700, Nicolin Chen wrote:
> static const struct iommu_domain_ops arm_smmu_nested_ops = {
> .get_msi_mapping_domain = arm_smmu_get_msi_mapping_domain,
> .attach_dev = arm_smmu_attach_dev_nested,
> .free = arm_smmu_domain_nested_free,
> + .c
On Tue, Aug 27, 2024 at 09:59:54AM -0700, Nicolin Chen wrote:
> +static int arm_smmu_viommu_cache_invalidate(struct iommufd_viommu *viommu,
> + struct iommu_user_data_array *array)
> +{
> + struct iommu_domain *domain = iommufd_viommu_to_parent_domain(vi
On Tue, Aug 27, 2024 at 09:59:47AM -0700, Nicolin Chen wrote:
> Driver can call the iommufd_viommu_find_device() to find a device pointer
> using its per-viommu virtual ID. The returned device must be protected by
> the pair of iommufd_viommu_lock/unlock_vdev_id() function.
>
> Put these three fun
and selftest case accordingly.
>
> Signed-off-by: Nicolin Chen
> ---
> drivers/iommu/iommufd/hw_pagetable.c| 32 +++--
> include/uapi/linux/iommufd.h| 9 ---
> tools/testing/selftests/iommu/iommufd.c | 4 ++--
> 3 files changed, 33
| 5 +
> include/linux/iommufd.h | 19 +++
> 4 files changed, 30 insertions(+)
It looks OK
Reviewed-by: Jason Gunthorpe
Jason
On Tue, Aug 27, 2024 at 09:59:43AM -0700, Nicolin Chen wrote:
> Introduce a pair of new ioctls to set/unset a per-viommu virtual device id
> that should be linked to a physical device id via an idev pointer.
Given some of the other discussions around CC I suspect we should
rename these to 'create/
; 3 files changed, 29 insertions(+), 8 deletions(-)
Reviewed-by: Jason Gunthorpe
Jason
On Tue, Aug 27, 2024 at 09:59:40AM -0700, Nicolin Chen wrote:
> With a viommu object wrapping a potentially shareable S2 domain, a nested
> domain should be allocated by associating to a viommu instead. Driver can
> store this viommu pointer somewhere, so as to later use it calling viommu
> helpers
On Tue, Aug 27, 2024 at 09:59:39AM -0700, Nicolin Chen wrote:
> +/**
> + * struct iommu_viommu_alloc - ioctl(IOMMU_VIOMMU_ALLOC)
> + * @size: sizeof(struct iommu_viommu_alloc)
> + * @flags: Must be 0
> + * @type: Type of the virtual IOMMU. Must be defined in enum
> iommu_viommu_type
> + * @dev_id:
On Tue, Aug 27, 2024 at 09:59:38AM -0700, Nicolin Chen wrote:
> Reorder struct forward declarations to alphabetic order to simplify
> maintenance, as upcoming patches will add more to the list.
>
> No functional change intended.
>
> Signed-off-by: Nicolin Chen
> ---
> include/linux/iommufd.h |
On Wed, Sep 04, 2024 at 10:29:26AM -0700, Nicolin Chen wrote:
> On Wed, Sep 04, 2024 at 01:26:21PM -0300, Jason Gunthorpe wrote:
> > On Sun, Sep 01, 2024 at 10:27:09PM -0700, Nicolin Chen wrote:
> > > On Sun, Sep 01, 2024 at 10:39:17AM +0800, Baolu Lu wrote:
> > > > O
On Sun, Sep 01, 2024 at 10:27:09PM -0700, Nicolin Chen wrote:
> On Sun, Sep 01, 2024 at 10:39:17AM +0800, Baolu Lu wrote:
> > On 2024/8/28 0:59, Nicolin Chen wrote:
> > > +int iommufd_viommu_alloc_ioctl(struct iommufd_ucmd *ucmd)
> > > +{
> > > + struct iommu_viommu_alloc *cmd = ucmd->cmd;
> >
On Wed, Sep 04, 2024 at 04:08:06AM +0800, Liu Jing wrote:
> If the file fails to open, not only return return1 but also close the file
> descriptor,otherwise resource
> leak will occur
Why doesn't FIXURE_TEARDOWN do this?
Jason
On Thu, Aug 22, 2024 at 10:17:56AM -0600, Mathieu Poirier wrote:
> > - domain = iommu_domain_alloc(dev->bus);
> > - if (!domain) {
> > + domain = iommu_paging_domain_alloc(dev);
>
> I'm a little hesitant here. Function iommu_domain_alloc() passes NULL two the
> second argument of __iommu_d
On Fri, Feb 09, 2024 at 08:55:31AM -0700, Alex Williamson wrote:
> I think Kevin's point is also relative to this latter scenario, in the
> L1 instance of the nvgrace-gpu driver the mmap of the usemem BAR is
> cachable, but in the L2 instance of the driver where we only use the
> vfio-pci-core ops
On Thu, Nov 09, 2023 at 06:48:46PM -0500, Michael S. Tsirkin wrote:
> On Tue, Nov 07, 2023 at 11:52:17AM -0400, Jason Gunthorpe wrote:
> > On Tue, Nov 07, 2023 at 09:30:21AM -0500, Michael S. Tsirkin wrote:
> > > On Tue, Nov 07, 2023 at 10:12:37AM -0400, Jason Gunthorpe
On Fri, Dec 23, 2022 at 03:51:55PM +0900, Daisuke Matsuda wrote:
> +static bool rxe_ib_invalidate_range(struct mmu_interval_notifier *mni,
> + const struct mmu_notifier_range *range,
> + unsigned long cur_seq)
> +{
> + struct ib_u
On Fri, Dec 23, 2022 at 03:51:54PM +0900, Daisuke Matsuda wrote:
> @@ -733,60 +734,83 @@ static enum resp_states process_flush(struct rxe_qp *qp,
> /* Guarantee atomicity of atomic operations at the machine level. */
> static DEFINE_SPINLOCK(atomic_ops_lock);
>
> -static enum resp_states atomic
On Mon, Jul 11, 2022 at 07:39:17PM -0700, Dan Williams wrote:
> Muchun Song wrote:
> > On Mon, Jul 04, 2022 at 11:38:16AM +0100, Matthew Wilcox wrote:
> > > On Mon, Jul 04, 2022 at 03:40:54PM +0800, Muchun Song wrote:
> > > > FSDAX page refcounts are 1-based, rather than 0-based: if refcount is
> >
On Fri, Aug 27, 2021 at 09:42:21AM -0700, Dan Williams wrote:
> On Fri, Aug 27, 2021 at 6:05 AM Li, Zhijian wrote:
> >
> >
> > on 2021/8/27 20:10, Jason Gunthorpe wrote:
> > > On Fri, Aug 27, 2021 at 08:15:40AM +, lizhij...@fujitsu.com wrote:
> >
On Fri, Aug 27, 2021 at 09:05:21PM +0800, Li, Zhijian wrote:
>
> on 2021/8/27 20:10, Jason Gunthorpe wrote:
> > On Fri, Aug 27, 2021 at 08:15:40AM +, lizhij...@fujitsu.com wrote:
> > > i looked over the change-log of hmm_vma_handle_pte(), and found that
> > >
On Fri, Aug 27, 2021 at 08:15:40AM +, lizhij...@fujitsu.com wrote:
> i looked over the change-log of hmm_vma_handle_pte(), and found that before
> 4055062 ("mm/hmm: add missing call to hmm_pte_need_fault in HMM_PFN_SPECIAL
> handling")
>
> hmm_vma_handle_pte() will not check pte_special(pte)
On Tue, Apr 20, 2021 at 04:04:57PM -0600, Alex Williamson wrote:
> > The migration control registers must be on a different VF from the VF
> > being plugged into a guest and the two VFs have to be in different
> > IOMMU groups to ensure they are isolated from each other.
>
> I think that's a solu
On Tue, Apr 20, 2021 at 05:28:33PM +0200, Christophe JAILLET wrote:
> 'in6' is unused. It is just declared and filled-in.
> It can be removed.
>
> This is a left over from commit 5ea8bbfc4929
> ("mlx4: Implement IP based gids support for RoCE/SRIOV")
>
> Signed-off-by: Christophe JAILLET
> ---
>
On Thu, Apr 15, 2021 at 05:21:16PM +0800, Wan Jiabing wrote:
> struct ipoib_cm_tx is defined at 245th line.
> And the definition is independent on the MACRO.
> The declaration here is unnecessary. Remove it.
>
> Signed-off-by: Wan Jiabing
> Reviewed-by: Christoph Lameter
> ---
> drivers/infinib
On Tue, Apr 20, 2021 at 09:28:46PM +0800, liulongfang wrote:
> >> So, I still don't understand what the security risk you are talking about
> >> is,
> >> and what do you think the security design should look like?
> >> Can you elaborate on it?
> >
> > Each security domain must have its own PCI BD
On Tue, Apr 20, 2021 at 08:50:12PM +0800, liulongfang wrote:
> On 2021/4/19 20:33, Jason Gunthorpe wrote:
> > On Mon, Apr 19, 2021 at 08:24:40PM +0800, liulongfang wrote:
> >
> >>> I'm also confused how this works securely at all, as a general rule a
> >>
On Tue, Apr 13, 2021 at 10:19:25PM +0800, Hao Sun wrote:
> Jason Gunthorpe 于2021年4月13日周二 下午9:45写道：
> >
> > On Tue, Apr 13, 2021 at 09:42:43PM +0800, Hao Sun wrote:
> > > Jason Gunthorpe 于2021年4月13日周二 下午9:34写道：
> > > >
> > > > On Tue, Apr 13, 2021
On Mon, Apr 19, 2021 at 08:24:40PM +0800, liulongfang wrote:
> > I'm also confused how this works securely at all, as a general rule a
> > VFIO PCI driver cannot access the MMIO memory of the function it is
> > planning to assign to the guest. There is a lot of danger that the
> > guest could acce
---
> 1 file changed, 12 insertions(+), 14 deletions(-)
Wow, yikes, that "kfree_const(dev->kobj.name);" is really creative
Reviewed-by: Jason Gunthorpe
Though I dislike ignoring the error code from dev_set_name(), I think
Greg would prefer this:
diff --git a/drivers/base/node.c b/
On Fri, Apr 16, 2021 at 10:23:32AM -0700, Jacob Pan wrote:
> Perhaps similar to cgroup v1 vs v2, it took a long time and with known
> limitations in v1.
cgroup v2 is still having transition problems, if anything it is a
cautionary tale to think really hard about uAPI because transitioning
can be
On Fri, Apr 16, 2021 at 04:26:19PM +0200, Auger Eric wrote:
> This was largely done during several confs including plumber, KVM forum,
> for several years. Also API docs were shared on the ML. I don't remember
> any voice was raised at those moments.
I don't think anyone objects to the high level
On Fri, Apr 16, 2021 at 03:38:02PM +0200, Auger Eric wrote:
> The redesign requirement came pretty late in the development process.
> The iommu user API is upstream for a while, the VFIO interfaces have
> been submitted a long time ago and under review for a bunch of time.
> Redesigning everything
On Thu, Apr 15, 2021 at 03:11:19PM +0200, Auger Eric wrote:
> Hi Jason,
>
> On 4/1/21 6:03 PM, Jason Gunthorpe wrote:
> > On Thu, Apr 01, 2021 at 02:08:17PM +, Liu, Yi L wrote:
> >
> >> DMA page faults are delivered to root-complex via page request message and
&
On Tue, Apr 13, 2021 at 11:36:22AM +0800, Longfang Liu wrote:
> Register the live migration driver of the accelerator module to vfio
>
> Signed-off-by: Longfang Liu
> drivers/vfio/pci/vfio_pci.c | 11 +++
> drivers/vfio/pci/vfio_pci_private.h | 9 +
> 2 files changed, 20
On Thu, Apr 15, 2021 at 04:47:34PM +1000, Stephen Rothwell wrote:
> Hi all,
>
> Today's linux-next merge of the vfio tree got a conflict in:
>
> drivers/gpu/drm/i915/gvt/gvt.c
>
> between commit:
>
> 9ff06c385300 ("drm/i915/gvt: Remove references to struct drm_device.pdev")
>
> from the dr
On Thu, Apr 15, 2021 at 01:33:24PM +0800, Lu Baolu wrote:
> Hi Jason,
>
> On 4/14/21 7:26 PM, Jason Gunthorpe wrote:
> > On Wed, Apr 14, 2021 at 02:22:09PM +0800, Lu Baolu wrote:
> >
> > > I still worry about supervisor pasid allocation.
> > >
> > &g
On Wed, Apr 14, 2021 at 02:41:52PM +, David Laight wrote:
> So whatever driver initialises the target needs to configure whatever
> target-specific register enables the RO transfers themselves.
RDMA in general, and mlx5 in particular, is a layered design:
mlx5_core <- owns the PCI function,
On Wed, Apr 14, 2021 at 10:16:28AM -0400, Tom Talpey wrote:
> On 4/12/2021 6:48 PM, Jason Gunthorpe wrote:
> > On Mon, Apr 12, 2021 at 04:20:47PM -0400, Tom Talpey wrote:
> >
> > > So the issue is only in testing all the providers and platforms,
> > > to be sure
On Wed, Apr 14, 2021 at 02:22:09PM +0800, Lu Baolu wrote:
> I still worry about supervisor pasid allocation.
>
> If we use iommu_sva_alloc_pasid() to allocate a supervisor pasid, which
> mm should the pasid be set? I've ever thought about passing &init_mm to
> iommu_sva_alloc_pasid(). But if you
On Tue, Apr 13, 2021 at 07:20:12PM +0200, Dmitry Vyukov wrote:
> > > Plus users are going to be seeing this as well. According to the commit
> > > message for 69bacee7f9ad ("mm: Add unsafe_follow_pfn") "Unfortunately
> > > there's some users where this is not fixable (like v4l userptr of iomem
> >
On Tue, Apr 13, 2021 at 05:11:03PM +0800, Jiapeng Chong wrote:
> Fix the following clang warning:
>
> drivers/infiniband/hw/qib/qib_iba7322.c:803:19: warning: unused function
> 'qib_read_ureg' [-Wunused-function].
>
> Reported-by: Abaci Robot
> Signed-off-by: Jiapeng Chong
> ---
> drivers/infi
On Tue, Apr 13, 2021 at 09:29:41AM +0300, Leon Romanovsky wrote:
> On Mon, Apr 12, 2021 at 07:58:47PM -0300, Jason Gunthorpe wrote:
> > On Wed, Mar 31, 2021 at 08:43:12PM +0200, Håkon Bugge wrote:
> > > ib_modify_qp() is an expensive operation on some HCAs running
> > &g
On Tue, Apr 13, 2021 at 09:42:43PM +0800, Hao Sun wrote:
> Jason Gunthorpe 于2021年4月13日周二 下午9:34写道：
> >
> > On Tue, Apr 13, 2021 at 11:36:41AM +0800, Hao Sun wrote:
> > > Hi
> > >
> > > When using Healer(https://github.com/SunHao-0/healer/tree/dev) to fu
On Tue, Apr 13, 2021 at 10:54:04AM +0200, Daniel Wagner wrote:
> Hmm, I am struggling with your last statement. If a worker does an
> allocation it might block. I understand this is something which a worker
> in a WQ_MEM_RECLAIM context is not allowed to do.
>
> My aim is still to get rid of the
On Tue, Apr 13, 2021 at 11:36:41AM +0800, Hao Sun wrote:
> Hi
>
> When using Healer(https://github.com/SunHao-0/healer/tree/dev) to fuzz
> the Linux kernel, I found two use-after-free bugs which have been
> reported a long time ago by Syzbot.
> Although the corresponding patches have been merged i
On Wed, Mar 31, 2021 at 08:43:12PM +0200, Håkon Bugge wrote:
> ib_modify_qp() is an expensive operation on some HCAs running
> virtualized. This series removes two ib_modify_qp() calls from RDS.
>
> I am sending this as a v3, even though it is the first sent to
> net. This because the IB Core comm
On Mon, Apr 12, 2021 at 04:20:47PM -0400, Tom Talpey wrote:
> So the issue is only in testing all the providers and platforms,
> to be sure this new behavior isn't tickling anything that went
> unnoticed all along, because no RDMA provider ever issued RO.
The mlx5 ethernet driver has run in RO mo
On Mon, Apr 12, 2021 at 06:35:35PM +, Haakon Bugge wrote:
>
>
> > On 7 Apr 2021, at 18:41, Haakon Bugge wrote:
> >
> >
> >
> >> On 1 Apr 2021, at 19:51, Jason Gunthorpe wrote:
> >>
> >> On Wed, Mar 31, 2021 at 07:54:17PM +,
On Thu, Apr 08, 2021 at 11:31:40AM +, Wang Wensheng wrote:
> Fix to return a negative error code from the error handling
> case instead of 0, as done elsewhere in this function.
>
> Fixes: 7724105686e7 ("IB/hfi1: add driver files")
> Reported-by: Hulk Robot
> Signed-off-by: Wang Wensheng
> -
On Thu, Apr 08, 2021 at 11:31:37AM +, Wang Wensheng wrote:
> Fix to return a negative error code from the error handling
> case instead of 0, as done elsewhere in this function.
>
> Fixes: 1ac5a4047975 ("RDMA/bnxt_re: Add bnxt_re RoCE driver")
> Reported-by: Hulk Robot
> Signed-off-by: Wang W
On Thu, Apr 08, 2021 at 11:31:35AM +, Wang Wensheng wrote:
> Fix to return a negative error code from the error handling
> case instead of 0, as done elsewhere in this function.
>
> Fixes: 82af6d19d8d9 ("RDMA/qedr: Fix synchronization methods and memory leaks
> in qedr")
> Reported-by: Hulk R
On Thu, Apr 08, 2021 at 09:50:30AM -0700, Bart Van Assche wrote:
> On 4/8/21 4:31 AM, Wang Wensheng wrote:
> > Fix to return a negative error code from the error handling
> > case instead of 0, as done elsewhere in this function.
> >
> > Fixes: db7683d7deb2 ("IB/srpt: Fix login-related race condit
On Mon, Apr 12, 2021 at 02:49:09PM +0200, Daniel Wagner wrote:
> I've grepped through the code and didn't find anything which supports
> the guarantee claim. Neither mm nor schedule seems to care about this
> flag nor workqueue.c (except the early init bits). Or I must miss
> something.
It is pre
On Mon, Apr 12, 2021 at 02:23:30PM +0200, Daniel Wagner wrote:
> Drop the WQ_MEM_RECLAIM flag as it is not needed and introduces
> warnings.
>
> The documentation says "all wq which might be used in the memory
> reclaim paths MUST have this flag set. The wq is guaranteed to have at
> least one exe
egistrR()
This movement looks OK though
Reviewed-by: Jason Gunthorpe
Jason
On Fri, Apr 09, 2021 at 08:24:00AM -0600, Alex Williamson wrote:
> > > #define DRIVER_VERSION "0.3"
> > > #define DRIVER_AUTHOR"Alex Williamson "
> > > #define DRIVER_DESC "VFIO - User Level meta-driver"
> > >
> > > +#define VFIO_MAGIC 0x5646494f /* "VFIO" */
> > Move to include/u
On Fri, Apr 09, 2021 at 12:20:09PM -0400, Dennis Dalessandro wrote:
> On 4/8/2021 6:00 PM, Stephen Rothwell wrote:
> > Hi all,
> >
> > Commit
> >
> >042a00f93aad ("IB/{ipoib,hfi1}: Add a timeout handler for rdma_netdev")
> >
> > is missing a Signed-off-by from its author.
>
> Doh! That's my
On Fri, Apr 09, 2021 at 10:26:21AM -0400, Tom Talpey wrote:
> My belief is that the biggest risk is from situations where completions
> are batched, and therefore polling is used to detect them without
> interrupts (which explicitly).
We don't do this in the kernel.
All kernel ULPs only read dat
Hi Linus,
Nothing very exciting here, just a few small bug fixes. No red flags
for this release have shown up.
Thanks,
Jason
The following changes since commit a5e13c6df0e41702d2b2c77c8ad41677ebb065b3:
Linux 5.12-rc5 (2021-03-28 15:48:16 -0700)
are available in the Git repository at:
git:
On Thu, Apr 08, 2021 at 01:38:17PM +0200, Daniel Vetter wrote:
> If you want to change this, we need automatic conflict resolution like apt
> and other package managers have, with suggestions how to fix the config if
> you want to enable a driver, but some of its requirements are missing. The
> cu
On Wed, Apr 07, 2021 at 03:44:35PM +, Parav Pandit wrote:
> > If it returns EOPNOTUPP then the remove is never called so if it allocated
> > memory and left it allocated then it is leaking memory.
> >
> I probably confused you. There is no leak today because add_one
> allocates memory, and la
On Wed, Apr 07, 2021 at 11:50:02PM +, Tian, Kevin wrote:
> > From: Jason Gunthorpe
> > Sent: Wednesday, April 7, 2021 8:21 PM
> >
> > On Wed, Apr 07, 2021 at 02:08:33AM +, Tian, Kevin wrote:
> >
> > > > Because if you don't th
On Sat, Apr 03, 2021 at 04:53:55AM +, Praveen Kumar Kannoju wrote:
> To update xlt (during mlx5_ib_reg_user_mr()), the driver can request up to
> 1 MB (order-8) memory, depending on the size of the MR. This costly
> allocation can sometimes take very long to return (a few seconds). This
> cause
On Wed, Apr 07, 2021 at 08:43:50PM +0200, Jean-Philippe Brucker wrote:
> * Get a container handle out of /dev/ioasid (or /dev/iommu, really.)
> No operation available since we don't know what the device and IOMMU
> capabilities are.
>
> * Attach the handle to a VF. With VFIO that would be
>
On Tue, Apr 06, 2021 at 04:54:57PM +0200, Christoph Hellwig wrote:
> On Tue, Apr 06, 2021 at 11:40:39AM -0300, Jason Gunthorpe wrote:
> > Yes, but the complexity is how the drivers are constructed they are
> > designed to reject flags they don't know about..
> >
> >
On Wed, Apr 07, 2021 at 03:06:35PM +, Parav Pandit wrote:
>
>
> > From: Jason Gunthorpe
> > Sent: Tuesday, April 6, 2021 9:17 PM
> >
> > On Mon, Apr 05, 2021 at 08:49:56AM +0300, Leon Romanovsky wrote:
> > > @@ -2293,6 +2295,17 @@ static v
On Wed, Apr 07, 2021 at 02:08:33AM +, Tian, Kevin wrote:
> > Because if you don't then we enter insane world where a PASID is being
> > created under /dev/ioasid but its translation path flows through setup
> > done by VFIO and the whole user API becomes an incomprehensible mess.
> >
> > How
On Wed, Apr 07, 2021 at 08:17:50AM +, Tian, Kevin wrote:
> > From: Jason Gunthorpe
> > Sent: Tuesday, April 6, 2021 8:43 PM
> >
> > On Tue, Apr 06, 2021 at 09:35:17AM +0800, Jason Wang wrote:
> >
> > > > VFIO and VDPA has no buisness having map/unma
On Wed, Apr 07, 2021 at 09:58:05AM +0800, Lu Baolu wrote:
> I've ever tried to implement a bus iommu_ops for mdev devices.
>
> https://lore.kernel.org/lkml/20201030045809.957927-1-baolu...@linux.intel.com/
>
> Any comments?
You still have the symbol_get, so something continues to be wrong with
On Mon, Mar 25, 2019 at 09:30:34AM +0800, Lu Baolu wrote:
> A parent device might create different types of mediated
> devices. For example, a mediated device could be created
> by the parent device with full isolation and protection
> provided by the IOMMU. One usage case could be found on
> Intel
On Mon, Apr 05, 2021 at 08:49:56AM +0300, Leon Romanovsky wrote:
> @@ -2293,6 +2295,17 @@ static void ib_sa_event(struct ib_event_handler
> *handler,
> }
> }
>
> +static bool ib_sa_client_supported(struct ib_device *device)
> +{
> + unsigned int i;
> +
> + rdma_for_each_port(devic
On Tue, Apr 06, 2021 at 04:15:52PM +0200, Christoph Hellwig wrote:
> On Tue, Apr 06, 2021 at 11:04:37AM -0300, Jason Gunthorpe wrote:
> > It might be idiodic, but I have to keep the uverbs thing working
> > too.
> >
> > There is a lot of assumption baked in to all the d
On Tue, Apr 06, 2021 at 02:30:34PM +0200, Christoph Hellwig wrote:
> On Tue, Apr 06, 2021 at 09:13:12AM -0300, Jason Gunthorpe wrote:
> > So we broadly have two choice
> > 1) Diverge the kernel and user interfaces and make the RDMA drivers
> > special case all the
On Tue, Apr 06, 2021 at 09:35:17AM +0800, Jason Wang wrote:
> > VFIO and VDPA has no buisness having map/unmap interfaces once we have
> > /dev/ioasid. That all belongs in the iosaid side.
> >
> > I know they have those interfaces today, but that doesn't mean we have
> > to keep using them for PA
On Tue, Apr 06, 2021 at 01:27:15AM +, Tian, Kevin wrote:
>
> and here is one example why using existing VFIO/VDPA interface makes
> sense. say dev1 (w/ sva) and dev2 (w/o sva) are placed in a single VFIO
> container.
Forget about SVA, it is an irrelevant detail of how a PASID is
configured.
On Tue, Apr 06, 2021 at 01:02:05AM +, Tian, Kevin wrote:
> > From: Jason Gunthorpe
> > Sent: Tuesday, April 6, 2021 7:40 AM
> >
> > On Fri, Apr 02, 2021 at 07:58:02AM +, Tian, Kevin wrote:
> > > > From: Jason Gunthorpe
> > > > Sent: Thursd
On Tue, Apr 06, 2021 at 12:37:35AM +, Tian, Kevin wrote:
> With nested translation it is GVA->GPA->HPA. The kernel needs to
> fix fault related to GPA->HPA (managed by VFIO/VDPA) while
> handle_mm_fault only handles HVA->HPA. In this case, the 2nd-level
> page fault is expected to be delivere
On Tue, Apr 06, 2021 at 08:58:54AM +0300, Leon Romanovsky wrote:
> On Tue, Apr 06, 2021 at 07:27:17AM +0200, Christoph Hellwig wrote:
> > On Tue, Apr 06, 2021 at 08:23:28AM +0300, Leon Romanovsky wrote:
> > > The same proposal (enable unconditionally) was raised during
> > > submission preparations
On Tue, Apr 06, 2021 at 08:09:43AM +0300, Leon Romanovsky wrote:
> On Tue, Apr 06, 2021 at 10:37:38AM +0800, Honggang LI wrote:
> > On Mon, Apr 05, 2021 at 08:23:54AM +0300, Leon Romanovsky wrote:
> > > From: Leon Romanovsky
> > >
> > > From Avihai,
> > >
> > > Relaxed Ordering is a PCIe mechani
On Mon, Apr 05, 2021 at 11:42:31PM +, Chuck Lever III wrote:
> We need to get a better idea what correctness testing has been done,
> and whether positive correctness testing results can be replicated
> on a variety of platforms.
RO has been rolling out slowly on mlx5 over a few years and st
On Fri, Apr 02, 2021 at 08:22:28AM +, Tian, Kevin wrote:
> > From: Jason Gunthorpe
> > Sent: Tuesday, March 30, 2021 9:29 PM
> >
> > >
> > > First, userspace may use ioasid in a non-SVA scenario where ioasid is
> > > bound to specific security c
On Fri, Apr 02, 2021 at 07:58:02AM +, Tian, Kevin wrote:
> > From: Jason Gunthorpe
> > Sent: Thursday, April 1, 2021 9:47 PM
> >
> > On Thu, Apr 01, 2021 at 01:43:36PM +, Liu, Yi L wrote:
> > > > From: Jason Gunthorpe
> > > > Sent: Thursd
On Fri, Apr 02, 2021 at 07:30:23AM +, Tian, Kevin wrote:
> > From: Jason Gunthorpe
> > Sent: Friday, April 2, 2021 12:04 AM
> >
> > On Thu, Apr 01, 2021 at 02:08:17PM +, Liu, Yi L wrote:
> >
> > > DMA page faults are delivered to root-complex via p
On Mon, Apr 05, 2021 at 03:41:15PM +0200, Christoph Hellwig wrote:
> On Mon, Apr 05, 2021 at 08:23:54AM +0300, Leon Romanovsky wrote:
> > From: Leon Romanovsky
> >
> > >From Avihai,
> >
> > Relaxed Ordering is a PCIe mechanism that relaxes the strict ordering
> > imposed on PCI transactions, and
On Fri, Apr 02, 2021 at 06:29:55PM -0700, Kees Cook wrote:
> On Fri, Apr 02, 2021 at 08:30:18PM -0300, Jason Gunthorpe wrote:
> > On Fri, Apr 02, 2021 at 04:03:30PM -0700, Kees Cook wrote:
> >
> > > > relevant. It seems to me that the hw_counters 'struct attribut
On Fri, Apr 02, 2021 at 04:03:30PM -0700, Kees Cook wrote:
> > relevant. It seems to me that the hw_counters 'struct attribute_group'
> > should probably be its own kobj within both of these structures so they
> > can have their own sysfs ops (unless there is some other way to do this
> > that I a
On Thu, Apr 01, 2021 at 10:10:28AM +0800, YueHaibing wrote:
> make W=1 warns this:
>
> In file included from drivers/infiniband/sw/rdmavt/mmap.c:51:0:
> ./include/rdma/uverbs_ioctl.h:937:1:
> warning: ‘_uverbs_get_const_unsigned’ defined but not used
> [-Wunused-function]
> _uverbs_get_const_un
On Thu, Apr 01, 2021 at 07:04:01AM +, Liu, Yi L wrote:
> After reading your reply in
> https://lore.kernel.org/linux-iommu/20210331123801.gd1463...@nvidia.com/#t
> So you mean /dev/ioasid FD is per-VM instead of per-ioasid, so above skeleton
> doesn't suit your idea.
You can do it one PASID
On Thu, Apr 01, 2021 at 01:43:36PM +, Liu, Yi L wrote:
> > From: Jason Gunthorpe
> > Sent: Thursday, April 1, 2021 9:16 PM
> >
> > On Thu, Apr 01, 2021 at 01:10:48PM +, Liu, Yi L wrote:
> > > > From: Jason Gunthorpe
> > > > Sent: Thursda
1 - 100 of 1346 matches
Mail list logo
