On Mon, Jun 24, 2024 at 10:36:13AM -0700, Easwar Hariharan wrote:
> Hi Jason,
>
> On 6/24/2024 9:32 AM, Jason Gunthorpe wrote:
> > On Mon, Jun 24, 2024 at 02:36:45PM +, Teddy Astie wrote:
> >>>> +bool xen_iommu_capable(struct device *dev, enum iommu_cap cap)
>
On Mon, Jun 24, 2024 at 02:36:45PM +, Teddy Astie wrote:
> >> +bool xen_iommu_capable(struct device *dev, enum iommu_cap cap)
> >> +{
> >> + switch (cap) {
> >> + case IOMMU_CAP_CACHE_COHERENCY:
> >> + return true;
> >
> > Will the PV-IOMMU only ever be exposed on hardware where th
On Thu, Jun 13, 2024 at 01:50:22PM +, Teddy Astie wrote:
> +struct iommu_domain *xen_iommu_domain_alloc(unsigned type)
> +{
> + struct xen_iommu_domain *domain;
> + u16 ctx_no;
> + int ret;
> +
> + if (type & IOMMU_DOMAIN_IDENTITY) {
> + /* use default domain */
> +
On Tue, Jun 20, 2023 at 01:01:39PM -0700, Vishal Moola wrote:
> On Fri, Jun 16, 2023 at 5:38 AM Jason Gunthorpe wrote:
> >
> > On Mon, Jun 12, 2023 at 02:03:53PM -0700, Vishal Moola (Oracle) wrote:
> > > Currently, page table information is stored within struct page. As p
On Mon, Jun 12, 2023 at 02:03:53PM -0700, Vishal Moola (Oracle) wrote:
> Currently, page table information is stored within struct page. As part
> of simplifying struct page, create struct ptdesc for page table
> information.
>
> Signed-off-by: Vishal Moola (Oracle)
> ---
> include/linux/pgtable
On Mon, May 01, 2023 at 12:27:55PM -0700, Vishal Moola (Oracle) wrote:
> The MM subsystem is trying to shrink struct page. This patchset
> introduces a memory descriptor for page table tracking - struct ptdesc.
>
> This patchset introduces ptdesc, splits ptdesc from struct page, and
> converts man
On Fri, Aug 05, 2022 at 10:53:36AM -0500, Bjorn Helgaas wrote:
> On Fri, Aug 05, 2022 at 09:10:41AM -0300, Jason Gunthorpe wrote:
> > On Fri, Aug 05, 2022 at 12:03:15PM +0200, Josef Johansson wrote:
> > > On 2/14/22 11:07, Josef Johansson wrote:
> > > > From: Josef J
ask &&
> >!desc.pci.msi_attrib.is_virtual;
> > - if (!desc.pci.msi_attrib.can_mask) {
> > + if (desc.pci.msi_attrib.can_mask) {
> > addr = pci_msix_desc_addr(&desc);
> > desc.pci.msix_ctrl = readl(addr +
> > PCI_MSIX_ENTRY_VECTOR_CTRL);
> > }
> >
Reviewed-by: Jason Gunthorpe
Bjorn, please take it?
Jason
On Wed, Mar 23, 2022 at 05:49:43PM +0100, Michal Hocko wrote:
> > The bug here is that prior to commit a81461b0546c ("xen/gntdev: update
> > to new mmu_notifier semantic") wired the mn_invl_range_start() which
> > takes a mutex to invalidate_page, which is defined to run in an atomic
> > context.
>
On Wed, Mar 23, 2022 at 10:45:30AM +0100, Michal Hocko wrote:
> [Let me add more people to the CC list - I am not really sure who is the
> most familiar with all the tricks that mmu notifiers might do]
>
> On Wed 23-03-22 09:43:59, Juergen Gross wrote:
> > Hi,
> >
> > during analysis of a custom
On Thu, Feb 10, 2022 at 05:55:32PM -0600, Bjorn Helgaas wrote:
> > Commit 71020a3c0dff4 ("PCI/MSI: Use msi_add_msi_desc()") modifies
> > the logic of checking msi_attrib.can_mask, without any reason.
> >
> > This commits restores that logic.
>
> I agree, this looks like a typo in 71020a3c0dff
; ---
> V2: Handle the INTx case directly instead of trying to be overly smart - Marc
> ---
> drivers/pci/msi/msi.c | 25 +
> 1 file changed, 5 insertions(+), 20 deletions(-)
Reviewed-by: Jason Gunthorpe
Jason
> 2 files changed, 38 insertions(+)
Reviewed-by: Jason Gunthorpe
Jason
c: "Cédric Le Goater"
> Cc: linuxppc-...@lists.ozlabs.org
>
> ---
> V2: Remove it completely - Cedric
> ---
> arch/powerpc/platforms/pseries/msi.c | 33 -
> 1 file changed, 8 insertions(+), 25 deletions(-)
Reviewed-by: Jason Gunthorpe
Jason
_enabled - Jason
> ---
> arch/powerpc/platforms/pseries/msi.c |3 +--
> 1 file changed, 1 insertion(+), 2 deletions(-)
Reviewed-by: Jason Gunthorpe
> --- a/arch/powerpc/platforms/pseries/msi.c
> +++ b/arch/powerpc/platforms/pseries/msi.c
> @@ -448,8 +4
lists.ozlabs.org
> ---
> V3: Use pci_dev property - Jason
> V2: Invoke the function with the correct number of arguments - Andy
> ---
> arch/powerpc/platforms/cell/axon_msi.c |5 +
> 1 file changed, 1 insertion(+), 4 deletions(-)
Reviewed-by: Jason Gunthorpe
Jason
> kernel/irq/msi.c | 17 ++---
> 1 file changed, 2 insertions(+), 15 deletions(-)
Reviewed-by: Jason Gunthorpe
Jason
5 +
> 1 file changed, 1 insertion(+), 4 deletions(-)
Reviewed-by: Jason Gunthorpe
Jason
d.
> ---
> arch/x86/pci/xen.c |9 ++---
> 1 file changed, 2 insertions(+), 7 deletions(-)
Reviewed-by: Jason Gunthorpe
Jason
-by: Thomas Gleixner
> ---
> V3: New patch
> ---
> drivers/pci/msi/msi.c | 23 +--
> 1 file changed, 17 insertions(+), 6 deletions(-)
Reviewed-by: Jason Gunthorpe
Jason
On Mon, Dec 06, 2021 at 11:51:02PM +0100, Thomas Gleixner wrote:
> This is the third part of [PCI]MSI refactoring which aims to provide the
> ability of expanding MSI-X vectors after enabling MSI-X.
I read through this and didn't have any substantive remarks
Reviewed-by: Jason Gunthorpe
Jason
On Mon, Dec 06, 2021 at 11:51:05PM +0100, Thomas Gleixner wrote:
> +++ b/kernel/irq/msi.c
> @@ -127,12 +127,37 @@ int msi_setup_device_data(struct device
> return -ENOMEM;
>
> INIT_LIST_HEAD(&md->list);
> + mutex_init(&md->mutex);
> dev->msi.data = md;
> devres
On Mon, Dec 06, 2021 at 11:39:26PM +0100, Thomas Gleixner wrote:
> Store the properties which are interesting for various places so the MSI
> descriptor fiddling can be removed.
>
> Signed-off-by: Thomas Gleixner
> ---
> V2: Use the setter function
> ---
> drivers/pci/msi/msi.c |8
>
On Mon, Dec 06, 2021 at 11:39:33PM +0100, Thomas Gleixner wrote:
> @@ -209,10 +209,10 @@ static int setup_msi_msg_address(struct
> return -ENODEV;
> }
>
> - entry = first_pci_msi_entry(dev);
> + is_64bit = msi_device_has_property(&dev->dev, MSI_PROP_64BIT);
How about
On Mon, Dec 06, 2021 at 11:39:28PM +0100, Thomas Gleixner wrote:
> instead of fiddling with MSI descriptors.
>
> Signed-off-by: Thomas Gleixner
> Reviewed-by: Greg Kroah-Hartman
> Reviewed-by: Jason Gunthorpe
> arch/x86/pci/xen.c |6 ++
> 1 file changed, 2 inser
On Mon, Dec 06, 2021 at 11:39:34PM +0100, Thomas Gleixner wrote:
> instead of fiddling with MSI descriptors.
>
> Signed-off-by: Thomas Gleixner
> Reviewed-by: Greg Kroah-Hartman
> Reviewed-by: Jason Gunthorpe
> arch/powerpc/platforms/pseries/msi.c |4 ++--
> 1 file
On Mon, Dec 06, 2021 at 11:39:29PM +0100, Thomas Gleixner wrote:
> instead of fiddling with MSI descriptors.
>
> Signed-off-by: Thomas Gleixner
> Reviewed-by: Greg Kroah-Hartman
> Reviewed-by: Jason Gunthorpe
> ---
> arch/x86/kernel/apic/msi.c |5 +
> 1 file ch
/msi/msi.c |2 +-
> drivers/pci/probe.c|4 +++-
> include/linux/device.h |2 --
> include/linux/pci.h|1 +
> 5 files changed, 5 insertions(+), 5 deletions(-)
Reviewed-by: Jason Gunthorpe
> --- a/drivers/base/core.c
> +++ b/drivers/base/core.c
> @@ -2
n stuff all that well anymore, but I read
through all the patches and only noticed a small spello
[patch 02/22] PCI/MSI: Fix pci_irq_vector()/pci_irq_get_attinity()
ff
It all seems good, I especially like the splitting of msi.c and
removal of ops..
Reviewed-by: Jason Gunthorpe
Thanks,
Jason
On Fri, Nov 20, 2020 at 12:21:39PM -0600, Gustavo A. R. Silva wrote:
> IB/hfi1: Fix fall-through warnings for Clang
> IB/mlx4: Fix fall-through warnings for Clang
> IB/qedr: Fix fall-through warnings for Clang
> RDMA/mlx5: Fix fall-through warnings for Clang
I picked these four to the rdm
On Wed, Aug 26, 2020 at 01:16:28PM +0200, Thomas Gleixner wrote:
> This is the second version of providing a base to support device MSI (non
> PCI based) and on top of that support for IMS (Interrupt Message Storm)
> based devices in a halfways architecture independent way.
Hi Thomas,
Our test te
On Mon, Oct 19, 2020 at 12:42:15PM -0700, Nick Desaulniers wrote:
> On Sat, Oct 17, 2020 at 10:43 PM Greg KH wrote:
> >
> > On Sat, Oct 17, 2020 at 09:09:28AM -0700, t...@redhat.com wrote:
> > > From: Tom Rix
> > >
> > > This is a upcoming change to clean up a new warning treewide.
> > > I am won
On Wed, Sep 30, 2020 at 01:08:27PM +, Derrick, Jonathan wrote:
> +Megha
>
> On Wed, 2020-09-30 at 09:57 -0300, Jason Gunthorpe wrote:
> > On Wed, Sep 30, 2020 at 12:45:30PM +, Derrick, Jonathan wrote:
> > > Hi Jason
> > >
> > > On Mon, 2020-0
On Wed, Sep 30, 2020 at 12:45:30PM +, Derrick, Jonathan wrote:
> Hi Jason
>
> On Mon, 2020-08-31 at 11:39 -0300, Jason Gunthorpe wrote:
> > On Wed, Aug 26, 2020 at 01:16:52PM +0200, Thomas Gleixner wrote:
> > > From: Thomas Gleixner
> > >
> > > De
On Wed, Sep 30, 2020 at 08:41:48AM +0200, Thomas Gleixner wrote:
> On Tue, Sep 29 2020 at 16:03, Megha Dey wrote:
> > On 8/26/2020 4:16 AM, Thomas Gleixner wrote:
> >> #9 is obviously just for the folks interested in IMS
> >>
> >
> > I see that the tip tree (as of 9/29) has most of these patches bu
On Wed, Aug 26, 2020 at 01:17:14PM +0200, Thomas Gleixner wrote:
> + * ims_queue_info - Information to create an IMS queue domain
> + * @queue_lock: Callback which informs the device driver that
> + * an interrupt management operation starts.
> + * @queue_sync_unlock:
On Wed, Aug 26, 2020 at 01:16:52PM +0200, Thomas Gleixner wrote:
> From: Thomas Gleixner
>
> Devices on the VMD bus use their own MSI irq domain, but it is not
> distinguishable from regular PCI/MSI irq domains. This is required
> to exclude VMD devices from getting the irq domain pointer set by
On Fri, Aug 28, 2020 at 01:47:59PM +0100, Marc Zyngier wrote:
> > So the arch_setup_msi_irq/etc is not really an arch hook, but some
> > infrastructure to support those 4 PCI root port drivers.
>
> I happen to have a *really old* patch addressing Tegra [1], which
> I was never able to test (no HW
On Fri, Aug 28, 2020 at 12:21:42PM +0100, Lorenzo Pieralisi wrote:
> On Thu, Aug 27, 2020 at 01:20:40PM -0500, Bjorn Helgaas wrote:
>
> [...]
>
> > And I can't figure out what's special about tegra, rcar, and xilinx
> > that makes them need it as well. Is there something I could grep for
> > to
On Sat, Aug 22, 2020 at 03:34:45AM +0200, Thomas Gleixner wrote:
> >> One question is whether the device can see partial updates to that
> >> memory due to the async 'swap' of context from the device CPU.
> >
> > It is worse than just partial updates.. The device operation is much
> > more like you
On Sat, Aug 22, 2020 at 01:47:12AM +0200, Thomas Gleixner wrote:
> On Fri, Aug 21 2020 at 17:17, Jason Gunthorpe wrote:
> > On Fri, Aug 21, 2020 at 09:47:43PM +0200, Thomas Gleixner wrote:
> >> So if I understand correctly then the queue memory where the MSI
> >>
On Fri, Aug 21, 2020 at 09:47:43PM +0200, Thomas Gleixner wrote:
> On Fri, Aug 21 2020 at 09:45, Jason Gunthorpe wrote:
> > On Fri, Aug 21, 2020 at 02:25:02AM +0200, Thomas Gleixner wrote:
> >> +static void ims_mask_irq(struct irq_data *data)
> >> +{
&g
On Fri, Aug 21, 2020 at 02:25:02AM +0200, Thomas Gleixner wrote:
> +static void ims_mask_irq(struct irq_data *data)
> +{
> + struct msi_desc *desc = irq_data_get_msi_desc(data);
> + struct ims_array_slot __iomem *slot = desc->device_msi.priv_iomem;
> + u32 __iomem *ctrl = &slot->ctrl;
>
s looks like it for the ptemod miss, thanks
Reviewed-by: Jason Gunthorpe
Jason
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
On Fri, Nov 22, 2019 at 04:54:08PM -0800, Ralph Campbell wrote:
> Actually, I think you can remove the "need_wake" variable since it is
> unconditionally set to "true".
Oh, yes, thank you. An earlier revision had a different control flow
> Also, the comment in__mmu_interval_notifier_insert() sa
On Wed, Nov 13, 2019 at 05:59:52AM -0800, Christoph Hellwig wrote:
> > +int mmu_interval_notifier_insert(struct mmu_interval_notifier *mni,
> > + struct mm_struct *mm, unsigned long start,
> > + unsigned long length,
> > +
From: Jason Gunthorpe
gntdev simply wants to monitor a specific VMA for any notifier events,
this can be done straightforwardly using mmu_interval_notifier_insert()
over the VMA's VA range.
The notifier should be attached until the original VMA is destroyed.
It is unclear if any of th
From: Jason Gunthorpe
Replace the internal interval tree based mmu notifier with the new common
mmu_interval_notifier_insert() API. This removes a lot of code and fixes a
deadlock that can be triggered in ODP:
zap_page_range()
mmu_notifier_invalidate_range_start
From: Jason Gunthorpe
Remove the interval tree in the driver and rely on the tree maintained by
the mmu_notifier for delivering mmu_notifier invalidation callbacks.
For some reason amdgpu has a very complicated arrangement where it tries
to prevent duplicate entries in the interval_tree, this
From: Jason Gunthorpe
Only the function calls are stubbed out with static inlines that always
fail. This is the standard way to write a header for an optional component
and makes it easier for drivers that only optionally need HMM_MIRROR.
Reviewed-by: Jérôme Glisse
Tested-by: Ralph Campbell
From: Jason Gunthorpe
Of the 13 users of mmu_notifiers, 8 of them use only
invalidate_range_start/end() and immediately intersect the
mmu_notifier_range with some kind of internal list of VAs. 4 use an
interval tree (i915_gem, radeon_mn, umem_odp, hfi1). 4 use a linked list
of some kind
From: Jason Gunthorpe
Convert the collision-retry lock around hmm_range_fault to use the one now
provided by the mmu_interval notifier.
Although this driver does not seem to use the collision retry lock that
hmm provides correctly, it can still be converted over to use the
mmu_interval_notifier
From: Jason Gunthorpe
Remove the hmm_mirror object and use the mmu_interval_notifier API instead
for the range, and use the normal mmu_notifier API for the general
invalidation callback.
While here re-organize the pagefault path so the locking pattern is clear.
nouveau is the only driver that
From: Jason Gunthorpe
The only two users of this are now converted to use mmu_interval_notifier,
delete all the code and update hmm.rst.
Reviewed-by: Jérôme Glisse
Tested-by: Ralph Campbell
Signed-off-by: Jason Gunthorpe
---
Documentation/vm/hmm.rst | 105 ---
include/linux
From: Jason Gunthorpe
find_vma() must be called under the mmap_sem, reorganize this code to
do the vma check after entering the lock.
Further, fix the unlocked use of struct task_struct's mm, instead use
the mm from hmm_mirror which has an active mm_grab. Also the mm_grab
must be converted
From: Jason Gunthorpe
This converts one of the two users of mmu_notifiers to use the new API.
The conversion is fairly straightforward, however the existing use of
notifiers here seems to be racey.
Tested-by: Dennis Dalessandro
Signed-off-by: Jason Gunthorpe
---
drivers/infiniband/hw/hfi1
From: Jason Gunthorpe
There is no reason to get the invalidate_range_start() callback via an
indirection through hmm_mirror, just register a normal notifier directly.
Tested-by: Ralph Campbell
Signed-off-by: Jason Gunthorpe
---
drivers/gpu/drm/nouveau/nouveau_svm.c | 95
From: Jason Gunthorpe
The new API is an exact match for the needs of radeon.
For some reason radeon tries to remove overlapping ranges from the
interval tree, but interval trees (and mmu_interval_notifier_insert())
support overlapping ranges directly. Simply delete all this code.
Since this
From: Jason Gunthorpe
Now that we have KERNEL_HEADER_TEST all headers are generally compile
tested, so relying on makefile tricks to avoid compiling code that depends
on CONFIG_MMU_NOTIFIER is more annoying.
Instead follow the usual pattern and provide most of the header with only
the functions
From: Jason Gunthorpe
hmm_mirror's handling of ranges does not use a sequence count which
results in this bug:
CPU0 CPU1
hmm_range_wait_until_valid(range)
valid ==
From: Jason Gunthorpe
8 of the mmu_notifier using drivers (i915_gem, radeon_mn, umem_odp, hfi1,
scif_dma, vhost, gntdev, hmm) drivers are using a common pattern where
they only use invalidate_range_start/end and immediately check the
invalidating range against some driver data structure to tell
On Thu, Nov 07, 2019 at 09:00:34PM -0500, Jerome Glisse wrote:
> On Fri, Nov 08, 2019 at 12:32:25AM +0000, Jason Gunthorpe wrote:
> > On Thu, Nov 07, 2019 at 04:04:08PM -0500, Jerome Glisse wrote:
> > > On Thu, Nov 07, 2019 at 08:11:06PM +0000, Jason Gunthorpe wrote:
> >
On Thu, Nov 07, 2019 at 12:53:56PM -0800, John Hubbard wrote:
> > > > +/**
> > > > + * struct mmu_range_notifier_ops
> > > > + * @invalidate: Upon return the caller must stop using any SPTEs
> > > > within this
> > > > + * range, this function can sleep. Return false if
> > > > block
On Thu, Nov 07, 2019 at 05:54:52PM -0500, Boris Ostrovsky wrote:
> On 11/7/19 3:36 PM, Jason Gunthorpe wrote:
> > On Tue, Nov 05, 2019 at 10:16:46AM -0500, Boris Ostrovsky wrote:
> >
> >>> So, I suppose it can be relaxed to a null test and a WARN_ON that it
> >
On Thu, Nov 07, 2019 at 04:04:08PM -0500, Jerome Glisse wrote:
> On Thu, Nov 07, 2019 at 08:11:06PM +0000, Jason Gunthorpe wrote:
> > On Wed, Nov 06, 2019 at 09:08:07PM -0500, Jerome Glisse wrote:
> >
> > > >
> > > > Extra credit: IMHO, t
On Tue, Nov 05, 2019 at 10:16:46AM -0500, Boris Ostrovsky wrote:
> > So, I suppose it can be relaxed to a null test and a WARN_ON that it
> > hasn't changed?
>
> You mean
>
> if (use_ptemod) {
> WARN_ON(map->vma != vma);
> ...
>
>
> Yes, that sounds good.
I amended my copy of
On Wed, Nov 06, 2019 at 09:08:07PM -0500, Jerome Glisse wrote:
> >
> > Extra credit: IMHO, this clearly deserves to all be in a new
> > mmu_range_notifier.h
> > header file, but I know that's extra work. Maybe later as a follow-up patch,
> > if anyone has the time.
>
> The range notifier should
On Wed, Nov 06, 2019 at 04:23:21PM -0800, John Hubbard wrote:
> Nice design, I love the seq foundation! So far, I'm not able to spot anything
> actually wrong with the implementation, sorry about that.
Alas :( I feel there must be a bug in here still, but onwards!
One of the main sad points wa
On Tue, Nov 05, 2019 at 01:23:46PM -0800, John Hubbard wrote:
> On 10/28/19 1:10 PM, Jason Gunthorpe wrote:
> > From: Jason Gunthorpe
> >
> > Now that we have KERNEL_HEADER_TEST all headers are generally compile
> > tested, so relying on makefile tricks to avoid
On Mon, Nov 04, 2019 at 05:03:31PM -0500, Boris Ostrovsky wrote:
> On 10/28/19 4:10 PM, Jason Gunthorpe wrote:
> > @@ -445,17 +438,9 @@ static void gntdev_vma_close(struct vm_area_struct
> > *vma)
> > struct gntdev_priv *priv = file->private_data;
> >
> >
On Fri, Nov 01, 2019 at 01:54:45PM -0700, Ralph Campbell wrote:
> You can add my Tested-by for the mm and nouveau changes.
> IOW, patches 1-4, 10-11, and 15.
>
> Tested-by: Ralph Campbell
Got it, thanks
Jason
___
Xen-devel mailing list
Xen-devel@list
On Mon, Oct 28, 2019 at 05:10:17PM -0300, Jason Gunthorpe wrote:
> From: Jason Gunthorpe
>
> 8 of the mmu_notifier using drivers (i915_gem, radeon_mn, umem_odp, hfi1,
> scif_dma, vhost, gntdev, hmm) drivers are using a common pattern where
> they only use invalidate_rang
On Fri, Nov 01, 2019 at 07:45:22PM +, Yang, Philip wrote:
> > This must be done inside the notifier_lock, after checking
> > mmu_range_read_retry(), all handling of the struct page must be
> > structured like that.
> >
> Below change will fix this, then driver will call mmu_range_read_retry
On Fri, Nov 01, 2019 at 02:51:46PM -0400, Boris Ostrovsky wrote:
> On 11/1/19 1:48 PM, Jason Gunthorpe wrote:
> > On Wed, Oct 30, 2019 at 12:55:37PM -0400, Boris Ostrovsky wrote:
> >> On 10/28/19 4:10 PM, Jason Gunthorpe wrote:
> >>> From: Jason Gunthorpe
>
without too much trouble.
This also deletes another place where a driver is associating additional
data (struct amdgpu_mn) with a mmu_struct.
Signed-off-by: Philip Yang
Reviewed-by: Philip Yang
Tested-by: Philip Yang
Signed-off-by: Jason Gunthorpe
---
.../gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
On Mon, Oct 28, 2019 at 05:10:25PM -0300, Jason Gunthorpe wrote:
> From: Jason Gunthorpe
>
> DMA_SHARED_BUFFER can not be enabled by the user (it represents a library
> set in the kernel). The kconfig convention is to use select for such
> symbols so they are turned on implicitl
On Fri, Nov 01, 2019 at 02:44:51PM +, Yang, Philip wrote:
> @@ -854,12 +853,20 @@ int amdgpu_ttm_tt_get_user_pages(struct amdgpu_bo *bo,
> struct page **pages)
> r = -EPERM;
> goto out_unlock;
> }
> + up_read(&mm->mmap_sem);
> + timeout = jiffies + mse
On Wed, Oct 30, 2019 at 12:55:37PM -0400, Boris Ostrovsky wrote:
> On 10/28/19 4:10 PM, Jason Gunthorpe wrote:
> > From: Jason Gunthorpe
> >
> > gntdev simply wants to monitor a specific VMA for any notifier events,
> > this can be done straightforwardly using mmu_r
On Fri, Nov 01, 2019 at 03:59:26PM +, Yang, Philip wrote:
> > This test for range_blockable should be before mutex_lock, I can move
> > it up
> >
> yes, thanks.
Okay, I wrote it like this:
if (mmu_notifier_range_blockable(range))
mutex_lock(&adev->notifier_lock);
On Fri, Nov 01, 2019 at 02:44:51PM +, Yang, Philip wrote:
>
>
> On 2019-10-29 3:25 p.m., Jason Gunthorpe wrote:
> > On Tue, Oct 29, 2019 at 07:22:37PM +, Yang, Philip wrote:
> >> Hi Jason,
> >>
> >> I did quick test after merging amd-staging-
On Tue, Oct 29, 2019 at 10:14:29PM +, Kuehling, Felix wrote:
> > +static const struct mmu_range_notifier_ops amdgpu_mn_hsa_ops = {
> > + .invalidate = amdgpu_mn_invalidate_hsa,
> > +};
> > +
> > +static int amdgpu_mn_sync_pagetables(struct hmm_mirror *mirror,
> > +
On Tue, Oct 29, 2019 at 10:04:45PM +, Kuehling, Felix wrote:
> >* because mm->mm_users > 0 during mmu_notifier_register and exit_mmap
> > @@ -52,17 +286,24 @@ struct mmu_notifier_mm {
> >* can't go away from under us as exit_mmap holds an mm_count pin
> >* itself.
> >*/
> > -vo
On Tue, Oct 29, 2019 at 07:22:37PM +, Yang, Philip wrote:
> Hi Jason,
>
> I did quick test after merging amd-staging-drm-next with the
> mmu_notifier branch, which includes this set changes. The test result
> has different failures, app stuck intermittently, GUI no display etc. I
> am under
On Tue, Oct 29, 2019 at 04:28:43PM +, Kuehling, Felix wrote:
> On 2019-10-28 4:10 p.m., Jason Gunthorpe wrote:
> > From: Jason Gunthorpe
> >
> > find_vma() must be called under the mmap_sem, reorganize this code to
> > do the vma check after entering the loc
On Tue, Oct 29, 2019 at 07:51:30AM +, Koenig, Christian wrote:
> > +static bool amdgpu_mn_invalidate_gfx(struct mmu_range_notifier *mrn,
> > +const struct mmu_notifier_range *range)
> > {
> > - struct amdgpu_bo *bo;
> > + struct amdgpu_bo *bo = container_of
On Tue, Oct 29, 2019 at 08:19:20AM -0400, Dennis Dalessandro wrote:
> On 10/28/2019 4:10 PM, Jason Gunthorpe wrote:
> > From: Jason Gunthorpe
> >
> > This converts one of the two users of mmu_notifiers to use the new API.
> > The conversion is fairly straightforward,
From: Jason Gunthorpe
Remove the interval tree in the driver and rely on the tree maintained by
the mmu_notifier for delivering mmu_notifier invalidation callbacks.
For some reason amdgpu has a very complicated arrangement where it tries
to prevent duplicate entries in the interval_tree, this
From: Jason Gunthorpe
The only two users of this are now converted to use mmu_range_notifier,
delete all the code and update hmm.rst.
Reviewed-by: Jérôme Glisse
Signed-off-by: Jason Gunthorpe
---
Documentation/vm/hmm.rst | 105 ---
include/linux/hmm.h | 183
From: Jason Gunthorpe
Convert the collision-retry lock around hmm_range_fault to use the one now
provided by the mmu_range notifier.
Although this driver does not seem to use the collision retry lock that
hmm provides correctly, it can still be converted over to use the
mmu_range_notifier api
From: Jason Gunthorpe
Of the 13 users of mmu_notifiers, 8 of them use only
invalidate_range_start/end() and immediately intersect the
mmu_notifier_range with some kind of internal list of VAs. 4 use an
interval tree (i915_gem, radeon_mn, umem_odp, hfi1). 4 use a linked list
of some kind
From: Jason Gunthorpe
The new API is an exact match for the needs of radeon.
For some reason radeon tries to remove overlapping ranges from the
interval tree, but interval trees (and mmu_range_notifier_insert)
support overlapping ranges directly. Simply delete all this code.
Since this driver
From: Jason Gunthorpe
DMA_SHARED_BUFFER can not be enabled by the user (it represents a library
set in the kernel). The kconfig convention is to use select for such
symbols so they are turned on implicitly when the user enables a kconfig
that needs them.
Otherwise the XEN_GNTDEV_DMABUF kconfig
From: Jason Gunthorpe
Replace the internal interval tree based mmu notifier with the new common
mmu_range_notifier_insert() API. This removes a lot of code and fixes a
deadlock that can be triggered in ODP:
zap_page_range()
mmu_notifier_invalidate_range_start
From: Jason Gunthorpe
Now that we have KERNEL_HEADER_TEST all headers are generally compile
tested, so relying on makefile tricks to avoid compiling code that depends
on CONFIG_MMU_NOTIFIER is more annoying.
Instead follow the usual pattern and provide most of the header with only
the functions
From: Jason Gunthorpe
find_vma() must be called under the mmap_sem, reorganize this code to
do the vma check after entering the lock.
Further, fix the unlocked use of struct task_struct's mm, instead use
the mm from hmm_mirror which has an active mm_grab. Also the mm_grab
must be converted
From: Jason Gunthorpe
There is no reason to get the invalidate_range_start() callback via an
indirection through hmm_mirror, just register a normal notifier directly.
Cc: Ben Skeggs
Cc: dri-de...@lists.freedesktop.org
Cc: nouv...@lists.freedesktop.org
Cc: Ralph Campbell
Signed-off-by: Jason
From: Jason Gunthorpe
hmm_mirror's handling of ranges does not use a sequence count which
results in this bug:
CPU0 CPU1
hmm_range_wait_until_valid(range)
valid ==
From: Jason Gunthorpe
Remove the hmm_mirror object and use the mmu_range_notifier API instead
for the range, and use the normal mmu_notifier API for the general
invalidation callback.
While here re-organize the pagefault path so the locking pattern is clear.
nouveau is the only driver that
From: Jason Gunthorpe
8 of the mmu_notifier using drivers (i915_gem, radeon_mn, umem_odp, hfi1,
scif_dma, vhost, gntdev, hmm) drivers are using a common pattern where
they only use invalidate_range_start/end and immediately check the
invalidating range against some driver data structure to tell
From: Jason Gunthorpe
Only the function calls are stubbed out with static inlines that always
fail. This is the standard way to write a header for an optional component
and makes it easier for drivers that only optionally need HMM_MIRROR.
Reviewed-by: Jérôme Glisse
Signed-off-by: Jason
1 - 100 of 107 matches
Mail list logo
