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
___
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 ins
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/iommu/dma
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..33fb4244e438 1006
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 10
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 disabled
interrupts - which works OK if you have only a couple of DMAR faults,
but becomes a problem if your intel iommu has a plenty of mappings.
We have a test that
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 __init for dmar_register_bus_not
Changes to v2:
- Ratelimit printks for dmar faults (6 patch)
First version:
https://lkml.org/lkml/2018/1/24/364
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 Ba
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/iommu/dma
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 disabled
interrupts - which works OK if you have only a couple of DMAR faults,
but becomes a problem if your intel iommu has a plenty of mappings.
We have a test that
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 ins
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 10
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..33fb4244e438 1006
There is a ratelimit for printing, but it's incremented each time the
cpu recives dmar fault interrupt. While one interrupt may signal about
*many* faults. And delayed to wq dmar fault work might receive even
more faults to clean, than it was earlier.
Ratelimit each fault printing rather than each
On Tue, 2018-02-13 at 17:35 +0100, Joerg Roedel wrote:
> On Mon, Feb 12, 2018 at 04:48:23PM +, 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
> > disabled
> > interrupts - whi
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 +, Dmitry Safonov wrote:
> > > dmar_fault() reports/handles/cleans DMAR faults in a cycle one-
> > > by-
> > > one.
> > > The nuisance is that
There is a ratelimit for printing, but it's incremented each time the
cpu recives dmar fault interrupt. While one interrupt may signal about
*many* faults.
So, measuring the impact it turns out that reading/clearing one fault
takes < 1 usec, and printing info about the fault takes ~170 msec.
Havin
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 interrupt. While one
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:
> > There is a ratelimit for pri
On Thu, 2018-03-15 at 14:46 +0100, Joerg Roedel wrote:
> On Thu, Feb 15, 2018 at 07:17:29PM +, Dmitry Safonov wrote:
> > diff --git a/drivers/iommu/dmar.c b/drivers/iommu/dmar.c
> > index accf58388bdb..6c4ea32ee6a9 100644
> > --- a/drivers/iommu/dmar.c
> > +++ b/drivers/iommu/dmar.c
> > @@ -161
On Thu, 2018-03-15 at 15:22 +0100, Joerg Roedel wrote:
> On Thu, Mar 15, 2018 at 02:13:03PM +, 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 and then PCI link flapped..
>
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 +, Dmitry Safonov wrote:
> > > So, you suggest to remove ratelimit at all?
> > > Do we really need printk flood for each happened fault?
> > >
On Thu, 2018-03-15 at 16:28 +0100, Joerg Roedel wrote:
> On Thu, Mar 15, 2018 at 02:42:00PM +, 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
> > anything else..
> > The pa
On Thu, 2018-03-15 at 16:28 +0100, Joerg Roedel wrote:
> On Thu, Mar 15, 2018 at 02:42:00PM +, 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
> > anything else..
> > The pa
There is a ratelimit for printing, but it's incremented each time the
cpu recives dmar fault interrupt. While one interrupt may signal about
*many* faults.
So, measuring the impact it turns out that reading/clearing one fault
takes < 1 usec, and printing info about the fault takes ~170 msec.
Havin
Theoretically, on some machines faults might be generated faster than
they're cleared by CPU. Let's limit the cleaning-loop by number of hw
fault registers.
Cc: Alex Williamson
Cc: David Woodhouse
Cc: Ingo Molnar
Cc: Joerg Roedel
Cc: Lu Baolu
Cc: iommu@lists.linux-foundation.org
Signed-off-by
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_iova_flush_queue(struct iova_domain *iovad)
> > +{
> > +
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
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 with !CONFIG_IOM
[ Upstream commit effa467870c7612012885df4e246bdb8ffd8e44c ]
Intel VT-d driver was reworked to use common deferred flushing
implementation. Previously there was one global per-cpu flush queue,
afterwards - one per domain.
Before deferring a flush, the queue should be allocated and initialized.
C
[ Upstream commit effa467870c7612012885df4e246bdb8ffd8e44c ]
Intel VT-d driver was reworked to use common deferred flushing
implementation. Previously there was one global per-cpu flush queue,
afterwards - one per domain.
Before deferring a flush, the queue should be allocated and initialized.
C
Backport commits from master that fix boot failure on some intel
machines.
I have only boot tested this in a VM. Functional testing for v4.14 is
out of my scope as patches differ only on a trivial conflict from v4.19,
where I discovered/debugged the issue. While testing v4.14 stable on
affected no
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
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 each time the
> cpu
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 a real case and this one was discussed
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 wrote:
> > > > Theoretically, on some machines faults migh
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 irq level triggered (or on edge) on lapic. S
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:
> > > > AFAICS, we're doing fault-clearing in a loop inside irq
> >
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 one solves softlockup for us, might be us
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 can be removed from the tree and freed
under rbtree lock. That happens during memory hot-unplug and cleanup on
module removal.
Here I cleanup users of the func
find_iova() holds iova_rbtree_lock only during the traversing rbtree.
After the lock is released, returned iova may be freed (e.g., during
module's release).
Hold the spinlock during search and removal of iova from the rbtree,
eleminating possible use-after-free or/and double-free of iova.
Cc: Dav
find_iova() grabs rbtree's spinlock only for the search time.
Nothing guaranties that returned iova still exist for __free_iova().
Prevent potential use-after-free and double-free by holding the spinlock
all the time iova is being searched and freed.
Cc: David Woodhouse
Cc: Joerg Roedel
Cc: iomm
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/iova.c | 2
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 can be removed from the t
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 (intel-iommu.c)
> > o drivers unload
45 matches
Mail list logo
