On Tue, 1 Dec 2020 at 21:50, Will Deacon wrote:
>
> On Tue, 17 Nov 2020 18:25:30 +0800, John Garry wrote:
> > This series contains a patch to solve the longterm IOVA issue which
> > leizhen originally tried to address at [0].
> >
> > A sieved kernel log is at the following, showing periodic dumps
+Cc: linux-...@vger.kernel.org
+Cc: Bjorn Helgaas
+Cc: Logan Gunthorpe
On 11/5/19 12:17 PM, James Sewart wrote:
> Any comments on this?
>
> Cheers,
> James.
>
>> On 24 Oct 2019, at 13:52, James Sewart wrote:
>>
>> The PLX PEX NTB forwards DMA transactions using Requester ID's that don't
>> e
On 8/6/19 11:47 PM, Dmitry Safonov wrote:
> Hi Pavel,
>
> On 8/3/19 10:34 PM, Pavel Machek wrote:
>> Hi!
>>
>>> --- a/drivers/iommu/intel-iommu.c
>>> +++ b/drivers/iommu/intel-iommu.c
>>> @@ -3721,7 +3721,7 @@ static void intel_unmap(struct device
Hi Pavel,
On 8/3/19 10:34 PM, Pavel Machek wrote:
> Hi!
>
>> --- a/drivers/iommu/intel-iommu.c
>> +++ b/drivers/iommu/intel-iommu.c
>> @@ -3721,7 +3721,7 @@ static void intel_unmap(struct device *d
>>
>> freelist = domain_unmap(domain, start_pfn, last_pfn);
>>
>> -if (intel_iommu_str
nodes would require porting some other [local] patches,
which is out of my timelimit for the backport.
Hopefully, that's fine.
Cc: David Woodhouse
Cc: Joerg Roedel
Cc: Joerg Roedel
Cc: Lu Baolu
Dmitry Safonov (1):
iommu/vt-d: Don't queue_iova() if there is no flush queue
Joerg
t;)
Signed-off-by: Dmitry Safonov
Reviewed-by: Lu Baolu
Signed-off-by: Joerg Roedel
[v4.14-port notes:
o minor conflict with untrusted IOMMU devices check under if-condition
o setup_timer() near one chunk is timer_setup() in v5.3]
Signed-off-by: Dmitry Safonov
---
drivers/iommu/intel-iommu.c | 2
t;)
Signed-off-by: Dmitry Safonov
Reviewed-by: Lu Baolu
Signed-off-by: Joerg Roedel
[v4.14-port notes:
o minor conflict with untrusted IOMMU devices check under if-condition]
Signed-off-by: Dmitry Safonov
---
drivers/iommu/intel-iommu.c | 2 +-
drivers/iommu/iova.c| 18 ++-
Backport commits from master that fix boot failure on some intel
machines.
Cc: David Woodhouse
Cc: Joerg Roedel
Cc: Joerg Roedel
Cc: Lu Baolu
Dmitry Safonov (1):
iommu/vt-d: Don't queue_iova() if there is no flush queue
Joerg Roedel (1):
iommu/iova: Fix compilation error
Hi Greg,
On 7/29/19 5:30 PM, gre...@linuxfoundation.org wrote:
>
> This is a note to let you know that I've just added the patch titled
>
> iommu/vt-d: Don't queue_iova() if there is no flush queue
>
> to the 5.2-stable tree which can be found at:
>
> http://www.kernel.org/git/?p=linux
On Tue 23 Jul 2019, 9:17 a.m. Joerg Roedel, wrote:
> On Tue, Jul 16, 2019 at 10:38:05PM +0100, Dmitry Safonov wrote:
>
> > @@ -235,6 +236,11 @@ static inline void init_iova_domain(struct
> iova_domain *iovad,
> > {
> > }
> >
> > +bool has_iov
pte entries
in dma_pte_clear_level().
Cc: David Woodhouse
Cc: Joerg Roedel
Cc: Lu Baolu
Cc: iommu@lists.linux-foundation.org
Signed-off-by: Dmitry Safonov
---
drivers/iommu/intel-iommu.c | 8 +---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/drivers/iommu/intel-iommu.c b/driv
0
RIP: 0010:_raw_spin_unlock_irqrestore+0x17/0x39
Cc: David Woodhouse
Cc: Joerg Roedel
Cc: Lu Baolu
Cc: iommu@lists.linux-foundation.org
Cc: # 4.14+
Fixes: 13cf01744608 ("iommu/vt-d: Make use of iova deferred flushing")
Signed-off-by: Dmitry Safonov
---
drivers/iommu/intel-iommu.
On 3/4/19 3:46 PM, James Sewart wrote:
> +static inline int domain_is_initialised(struct dmar_domain *domain)
> +{
> + return domain->flags & DOMAIN_FLAG_INITIALISED;
> +}
Maybe check it in intel_iommu_domain_free(), eh?
Thanks,
Dmitry
___
On Fri, 2018-07-06 at 17:13 +0200, Joerg Roedel wrote:
> On Fri, Jul 06, 2018 at 03:10:47PM +0100, Dmitry Safonov wrote:
> > Yes, as far as I can see, there are code-paths which may try to
> > handle
> > it at the same time:
> > o memory notifiers for hot-unplug (i
On Fri, 2018-07-06 at 15:16 +0200, Joerg Roedel wrote:
> On Thu, Jun 21, 2018 at 07:08:20PM +0100, Dmitry Safonov wrote:
> > find_iova() looks to be using a bad locking practice: it locks the
> > returned iova only for the search time. And looking in code, the
> > element ca
Hi,
Any opinion on that?
It looks to remove a source of possible issues and
has a nice diffstat.
2018-06-21 19:08 GMT+01:00 Dmitry Safonov :
> find_iova() looks to be using a bad locking practice: it locks the
> returned iova only for the search time.
> And looking in code, the eleme
This function is potentially dangerous: nothing protects returned iova.
As there is no user in tree anymore, delete it.
Cc: David Woodhouse
Cc: Joerg Roedel
Cc: iommu@lists.linux-foundation.org
Cc: Dmitry Safonov <0x7f454...@gmail.com>
Signed-off-by: Dmitry Safonov
---
drivers/iommu/
l
Cc: iommu@lists.linux-foundation.org
Cc: Dmitry Safonov <0x7f454...@gmail.com>
Signed-off-by: Dmitry Safonov
---
drivers/iommu/iova.c | 9 ++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/drivers/iommu/iova.c b/drivers/iommu/iova.c
index 4b38eb507670..4c63d92afaf7 1
.
Cc: David Woodhouse
Cc: Joerg Roedel
Cc: iommu@lists.linux-foundation.org
Cc: Dmitry Safonov <0x7f454...@gmail.com>
Signed-off-by: Dmitry Safonov
---
drivers/iommu/intel-iommu.c | 14 +++---
drivers/iommu/iova.c| 19 ---
include/linux/iova.h| 10 ++
function and delete it.
Dmitry Safonov (3):
iommu/iova: Find and split iova under rbtree's lock
iommu/iova: Make free_iova() atomic
iommu/iova: Remove find_iova()
drivers/iommu/intel-iommu.c | 14 +++--
drivers/iommu/iova.c
On Thu, 2018-05-03 at 14:40 +0200, Joerg Roedel wrote:
> On Wed, May 02, 2018 at 03:22:24AM +0100, Dmitry Safonov wrote:
> > Hi Joerg,
> >
> > is there anything I may do about those two patches?
> > In 2/2 I've limited loop cnt as discussed in v3.
> > This
On Thu, 2018-05-03 at 10:16 +0800, Lu Baolu wrote:
> Hi,
>
> On 05/03/2018 09:59 AM, Dmitry Safonov wrote:
> > On Thu, 2018-05-03 at 09:32 +0800, Lu Baolu wrote:
> > > Hi,
> > >
> > > On 05/03/2018 08:52 AM, Dmitry Safonov wrote:
> > > > A
On Thu, 2018-05-03 at 09:32 +0800, Lu Baolu wrote:
> Hi,
>
> On 05/03/2018 08:52 AM, Dmitry Safonov wrote:
> > AFAICS, we're doing fault-clearing in a loop inside irq handler.
> > That means that while we're clearing if a fault raises, it'll make
> > an
On Thu, 2018-05-03 at 07:49 +0800, Lu Baolu wrote:
> Hi,
>
> On 05/02/2018 08:38 PM, Dmitry Safonov wrote:
> > Hi Lu,
> >
> > On Wed, 2018-05-02 at 14:34 +0800, Lu Baolu wrote:
> > > Hi,
> > >
> > > On 03/31/2018 08:33 AM, Dmitry Safonov
Hi Lu,
On Wed, 2018-05-02 at 14:34 +0800, Lu Baolu wrote:
> Hi,
>
> On 03/31/2018 08:33 AM, Dmitry Safonov wrote:
> > Theoretically, on some machines faults might be generated faster
> > than
> > they're cleared by CPU.
>
> Is this a real case?
No. 1/2 is
Hi Joerg,
is there anything I may do about those two patches?
In 2/2 I've limited loop cnt as discussed in v3.
This one solves softlockup for us, might be useful.
On Sat, 2018-03-31 at 01:33 +0100, Dmitry Safonov wrote:
> There is a ratelimit for printing, but it's incremented
\n'
[..] printk+0x4d/0x4f$\n'
[..] dmar_fault+0x1a8/0x1fc$\n'
[..] dmar_fault_work+0x15/0x17$\n'
[..] process_one_work+0x1e8/0x3a9$\n'
[..] worker_thread+0x25d/0x345$\n'
[..] kthread+0xea/0xf2$\n'
[..] ret_from_fork+0x58/0x90$\n'
Cc: Alex Williamson
Cc: David
Signed-off-by: Dmitry Safonov
---
drivers/iommu/dmar.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/iommu/dmar.c b/drivers/iommu/dmar.c
index 6c4ea32ee6a9..cf1105111209 100644
--- a/drivers/iommu/dmar.c
+++ b/drivers/iommu/dmar.c
@@ -1615,7 +1615,7 @@
2018-03-29 9:50 GMT+01:00 Joerg Roedel :
> On Tue, Mar 20, 2018 at 08:50:13PM +0000, Dmitry Safonov wrote:
>> Hmm, but this fixes my softlockup issue, because it's about time spent
>> in printk() inside irq-disabled section, rather about exiting the dmar-
>> clearing loo
On Thu, 2018-03-15 at 16:28 +0100, Joerg Roedel wrote:
> On Thu, Mar 15, 2018 at 02:42:00PM +0000, Dmitry Safonov wrote:
> > But even with loop-limit we will need ratelimit each printk()
> > *also*.
> > Otherwise loop-limit will be based on time spent printing, not on
> &
On Thu, 2018-03-15 at 16:28 +0100, Joerg Roedel wrote:
> On Thu, Mar 15, 2018 at 02:42:00PM +0000, Dmitry Safonov wrote:
> > But even with loop-limit we will need ratelimit each printk()
> > *also*.
> > Otherwise loop-limit will be based on time spent printing, not on
> &
On Thu, 2018-03-15 at 14:34 +, Dmitry Safonov wrote:
> On Thu, 2018-03-15 at 15:22 +0100, Joerg Roedel wrote:
> > On Thu, Mar 15, 2018 at 02:13:03PM +0000, Dmitry Safonov wrote:
> > > So, you suggest to remove ratelimit at all?
> > > Do we really need printk fl
On Thu, 2018-03-15 at 15:22 +0100, Joerg Roedel wrote:
> On Thu, Mar 15, 2018 at 02:13:03PM +0000, Dmitry Safonov wrote:
> > So, you suggest to remove ratelimit at all?
> > Do we really need printk flood for each happened fault?
> > Imagine, you've hundreds of mappings
On Thu, 2018-03-15 at 14:46 +0100, Joerg Roedel wrote:
> On Thu, Feb 15, 2018 at 07:17:29PM +0000, Dmitry Safonov wrote:
> > diff --git a/drivers/iommu/dmar.c b/drivers/iommu/dmar.c
> > index accf58388bdb..6c4ea32ee6a9 100644
> > --- a/drivers/iommu/dmar.c
> >
Gentle ping?
On Mon, 2018-03-05 at 15:00 +, Dmitry Safonov wrote:
> Hi Joerg,
>
> What do you think about v3?
> It looks like, I can solve my softlookups with just a bit more proper
> ratelimiting..
>
> On Thu, 2018-02-15 at 19:17 +, Dmitry Safonov wrote:
> &g
Hi Joerg,
What do you think about v3?
It looks like, I can solve my softlookups with just a bit more proper
ratelimiting..
On Thu, 2018-02-15 at 19:17 +, Dmitry Safonov wrote:
> There is a ratelimit for printing, but it's incremented each time the
> cpu recives dmar fault inter
\n'
[..] printk+0x4d/0x4f$\n'
[..] dmar_fault+0x1a8/0x1fc$\n'
[..] dmar_fault_work+0x15/0x17$\n'
[..] process_one_work+0x1e8/0x3a9$\n'
[..] worker_thread+0x25d/0x345$\n'
[..] kthread+0xea/0xf2$\n'
[..] ret_from_fork+0x58/0x90$\n'
Cc: Alex Williamson
Cc: David
On Tue, 2018-02-13 at 17:38 +, Dmitry Safonov wrote:
> On Tue, 2018-02-13 at 17:35 +0100, Joerg Roedel wrote:
> > On Mon, Feb 12, 2018 at 04:48:23PM +0000, Dmitry Safonov wrote:
> > > dmar_fault() reports/handles/cleans DMAR faults in a cycle one-
> > > by-
>
On Tue, 2018-02-13 at 17:35 +0100, Joerg Roedel wrote:
> On Mon, Feb 12, 2018 at 04:48:23PM +0000, Dmitry Safonov wrote:
> > dmar_fault() reports/handles/cleans DMAR faults in a cycle one-by-
> > one.
> > The nuisance is that it's set as a irq handler and runs with
&
7;
[..] vprintk_emit+0x39e/0x3e6$\n'
[..] printk+0x4d/0x4f$\n'
[..] dmar_fault+0x1a8/0x1fc$\n'
[..] dmar_fault_work+0x15/0x17$\n'
[..] process_one_work+0x1e8/0x3a9$\n'
[..] worker_thread+0x25d/0x345$\n'
[..] kthread+0xea/0xf2$\n'
[..] ret_from_fork+0x58/0x90$\n'
Fix the return value, parameters and a bit better naming.
Signed-off-by: Dmitry Safonov
---
drivers/iommu/dmar.c| 8 +++-
drivers/iommu/intel-iommu.c | 2 +-
drivers/iommu/intel_irq_remapping.c | 2 +-
include/linux/dmar.h| 2 +-
4 files changed, 6
0x47d
x86_64_start_reservations+0x2a/0x2c
x86_64_start_kernel+0x14b/0x15a
Move DMAR faults clearing out of irq-disabled critical section by
proceeding with that in a workqueue thread.
The next patch will correct the definition of dmar_fault().
Signed-off-by: Dmitry Safonov
---
drivers/iommu/d
So one could decode them without opening the specification.
Signed-off-by: Dmitry Safonov
---
include/linux/intel-iommu.h | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/include/linux/intel-iommu.h b/include/linux/intel-iommu.h
index 8dad3dd26eae..ef169d67df92
To my mind it's a bit more readable - and I will re-use it in the next
patch.
Signed-off-by: Dmitry Safonov
---
drivers/iommu/dmar.c | 12 ++--
1 file changed, 10 insertions(+), 2 deletions(-)
diff --git a/drivers/iommu/dmar.c b/drivers/iommu/dmar.c
index accf58388bdb..33fb424
c: Lu Baolu
Cc: iommu@lists.linux-foundation.org
Dmitry Safonov (6):
iommu/intel: Add __init for dmar_register_bus_notifier()
iommu/intel: Clean/document fault status flags
iommu/intel: Introduce clear_primary_faults() helper
iommu/intel: Handle DMAR faults on workqueue
iommu/intel: R
It's called only from intel_iommu_init(), which is init function.
Signed-off-by: Dmitry Safonov
---
drivers/iommu/dmar.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/iommu/dmar.c b/drivers/iommu/dmar.c
index 9a7ffd13c7f0..accf58388bdb 100644
--- a/drivers/
So one could decode them without opening the specification.
Signed-off-by: Dmitry Safonov
---
include/linux/intel-iommu.h | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/include/linux/intel-iommu.h b/include/linux/intel-iommu.h
index f3274d9f46a2..a4dc9c2875cc
0x47d
x86_64_start_reservations+0x2a/0x2c
x86_64_start_kernel+0x14b/0x15a
Move DMAR faults clearing out of irq-disabled critical section by
proceeding with that in a workqueue thread.
The next patch will correct the definition of dmar_fault().
Signed-off-by: Dmitry Safonov
---
drivers/iommu/d
A softlockup-panic fix I've meet on kernel test suite.
While at it, fix a couple of minor issues.
Cc: Alex Williamson
Cc: David Woodhouse
Cc: Ingo Molnar
Cc: Joerg Roedel
Cc: Lu Baolu
Cc: iommu@lists.linux-foundation.org
Dmitry Safonov (5):
iommu/intel: Add __ini
To my mind it's a bit more readable - and I will re-use it in the next
patch.
Signed-off-by: Dmitry Safonov
---
drivers/iommu/dmar.c | 12 ++--
1 file changed, 10 insertions(+), 2 deletions(-)
diff --git a/drivers/iommu/dmar.c b/drivers/iommu/dmar.c
index accf58388bdb..33fb424
It's called only from intel_iommu_init(), which is init function.
Signed-off-by: Dmitry Safonov
---
drivers/iommu/dmar.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/iommu/dmar.c b/drivers/iommu/dmar.c
index 9a7ffd13c7f0..accf58388bdb 100644
--- a/drivers/
Fix the return value, parameters and a bit better naming.
Signed-off-by: Dmitry Safonov
---
drivers/iommu/dmar.c| 8 +++-
drivers/iommu/intel-iommu.c | 2 +-
drivers/iommu/intel_irq_remapping.c | 2 +-
include/linux/dmar.h| 2 +-
4 files changed, 6
52 matches
Mail list logo
