On Mon, 2016-12-05 at 13:58 -0800, Kees Cook wrote:
> This blacklists the Q35 integrated graphics so IOMMU can be otherwise
> enabled. Without this, a Q35 system can only enable IOMMU when booting
> with "intel_iommu=on,igfx_off" but not "intel_iommu=on".
Hm, is this definitely the same bug? Or is
On Mon, 2016-12-05 at 14:18 -0800, Kees Cook wrote:
> Hm, I have no idea. :) What would I look for in the BIOS?
For a start, what is the actual failure mode?
> I figured since g4 was busted, surely q35 was too, since it's even
> older...
Oh no, they all have different failures. Intel never actua
On Mon, 2017-02-27 at 19:54 +, Jean-Philippe Brucker wrote:
> Add three functions to the IOMMU API. iommu_bind_task takes a device and a
> task as argument. If the IOMMU, the device and the bus support it, attach
> task to device and create a Process Address Space ID (PASID) unique to the
> dev
ve been cached ever since. So make sure to flush the IOTLB as well
> when we destroy these old copied mappings.
>
> Cc: Joerg Roedel
> Cc: David Woodhouse
> Cc: David Woodhouse
> Cc: Anthony Liguori
> Signed-off-by: KarimAllah Ahmed
Acked-by: David Woodhouse
Cc: sta...
On Wed, 2017-05-10 at 22:49 -0500, Gustavo A. R. Silva wrote:
> did_old is an unsigned variable and, greater-than-or-equal-to-zero
> comparison of an unsigned variable is always true.
>
> Addresses-Coverity-ID: 1398477
> Signed-off-by: Gustavo A. R. Silva
So... why do you think that check was th
On Thu, 2017-06-01 at 13:30 +0100, Jean-Philippe Brucker wrote:
>
> Yes, the current plan is to create a PASID (SSID) allocator that could be
> used by AMD, Intel, ARM, and other IOMMUs. Currently the kfd driver
> allocates PASIDs, but this will be done by the IOMMU subsystem in the
> future. Writ
've occasionally spoken about working around such a
problem by setting a bit to make subsequent faults *silent*. Would that
work?
> What we have to do is stopping DMA transaction
> before DMA-remapping is disabled in 2nd kernel.
The IOMMU is there to stop DMA transactions. That is its *job*. :
On Thu, 2013-04-04 at 14:48 +0900, Takao Indoh wrote:
>
> - DMAR fault messages floods and second kernel does not boot. Recently I
> saw similar report. https://lkml.org/lkml/2013/3/8/120
Right. So the fix for that is to make the subsequent errors silent,
until/unless we actually get a request
On Wed, 2013-04-03 at 17:53 -0600, Bjorn Helgaas wrote:
> );
> > +
> > + if ((revision == 0x13) && irq_remapping_enabled) {
> > +pr_warn(HW_ERR "This system BIOS has enabled interrupt
> > remapping\n"
> > +"on a chipset that contains an errata making
On Tue, 2013-07-09 at 17:18 -0700, Guenter Roeck wrote:
>
> I meant warning as in pr_warn or dev_warn, not WARNING as in traceback.
> Keep in mind that a casual user doesn't expect to see a traceback and will
> tend
> to get alarmed. Several bugs have been filed against this "issue" in various
>
oing* DMA, seems wrong.
You'll even end up resetting devices just because they have an RMRR,
won't you? (Although I wouldn't lose any sleep over that, I suppose. In
fact it might be a *feature*... :)
--
David WoodhouseOpen Source Technology Centre
david.wood
On Tue, 2013-09-10 at 14:43 +0900, Takao Indoh wrote:
> (2013/09/09 18:07), David Woodhouse wrote:
> > If the driver is so broken that it cannot get the device working again
> > after a fault, surely the driver needs to be fixed?
>
> Yes,this problem may be solved by fi
else
iommu_flush_write_buffer(iommu);
@@ -4116,7 +4227,10 @@ static size_t intel_iommu_unmap(struct iommu_domain
*domain,
int order;
order = dma_pte_clear_range(dmar_domain, iova >> VTD_PAGE_SHIFT,
- (iova + size - 1)
On Tue, 2013-09-24 at 15:16 +0200, Joerg Roedel wrote:
>
> I am not convinced that this is the right approach. If a device wasn't
> translated by VT-d in the old kernel doesn't mean it will not be
> translated in the new kernel. How about unconditionally resetting all
> PCI busses and/or functions
On Wed, 2013-09-25 at 17:54 +0200, Joerg Roedel wrote:
> On Sat, Sep 21, 2013 at 09:59:00PM -0500, David Woodhouse wrote:
> > I *hate* the bizarre calling convention for iommu_unmap(). Is it
> > actually clearly documented anywhere? Why on earth is it not just
> > returning
On Wed, 2013-09-25 at 11:36 -0600, Alex Williamson wrote:
> On Wed, 2013-09-25 at 17:05 +0100, David Woodhouse wrote:
> > Why would it ever care? If it *happens* to map something that can use
> > large pages, yay!. If it subsequently breaks apart those large pages by
> >
On Wed, 2013-09-25 at 13:44 -0600, Alex Williamson wrote:
> On Wed, 2013-09-25 at 19:52 +0100, David Woodhouse wrote:
> > On Wed, 2013-09-25 at 11:36 -0600, Alex Williamson wrote:
> > > On Wed, 2013-09-25 at 17:05 +0100, David Woodhouse wrote:
> > > > Why would it eve
On Wed, 2013-09-25 at 15:46 -0600, Alex Williamson wrote:
> On Wed, 2013-09-25 at 21:11 +0100, David Woodhouse wrote:
> > I wouldn't bother to go looking for opportunities to use super pages if
> > we remove the last non-SP-capable IOMMU from the domain.
>
> I predi
On Sat, 2013-09-21 at 21:59 -0500, David Woodhouse wrote:
> Here's a completely untested work-in-progress that attempts to fix that.
> I'll be able to test it myself on about Tuesday when I'm home from New
> Orleans and awake...
Or might have been if my laptop's hard
andle more than one page at a time, let
it loop for *itself* over the pages.
--
David WoodhouseOpen Source Technology Centre
david.woodho...@intel.com Intel Corporation
smime.p7s
Description: S/MIME cryptographic signature
_
On Mon, 2013-11-11 at 16:09 -0700, Alex Williamson wrote:
> On Thu, 2013-11-07 at 16:37 +0000, David Woodhouse wrote:
> > On Fri, 2013-05-24 at 11:14 -0600, Alex Williamson wrote:
> > > iommu_map splits requests into pages that the iommu driver reports
> > > that it c
On Fri, 2013-11-08 at 08:46 -0700, Bjorn Helgaas wrote:
>
> I don't know the IOMMU drivers well either, but it seems like they
> rely on notifications of device addition and removal (see
> iommu_bus_notifier()). It doesn't seem right for them to also use the
> generic PCI interfaces like pci_get_
ormance
of large unmaps.
As a side-effect of all these changes, this also fixes the fact that
intel_iommu_unmap() was neglecting to free the page tables for the range
in question after clearing them.
Signed-off-by: David Woodhouse
---
Potential issues:
- Is it OK to use page->freelis
On Wed, 2014-02-19 at 14:07 +0800, Jiang Liu wrote:
> Current Intel DMAR/IOMMU driver assumes that all PCI devices
> associated
> with DMAR/RMRR/ATSR device scope arrays are created at boot time and
> won't change at runtime, so it caches pointers of associated PCI
> device
> object. That assumptio
On Mon, 2014-03-10 at 16:46 +0800, Jiang Liu wrote:
> Hi David,
> Good suggestion! It should make hotplug logic simpler too.
> Will try to work out some patches for it.
Before doing so, please be aware of the WIP at
http://git.infradead.org/users/dwmw2/linux-andd.git
This is the support f
not* happen. If there *are* no
IOMMUs in the system which are non-coherent, then we don't need to do
it. And flushing the dcache is a *significant* performance hit.
Signed-off-by: David Woodhouse
---
In fact, even the overly cautious approach is broken because it's possible
to add a coheren
t; PAGE_SHIFT,
kvm_unpin_pages, kvm);
}
void kvm_iommu_unmap_pages(struct kvm *kvm, struct kvm_memory_slot *slot)
--
David WoodhouseOpen Source Technology Centre
david.woodho...@intel.com Intel Corporation
smim
On Mon, 2014-03-17 at 09:44 -0600, Alex Williamson wrote:
>
>
> As mentioned on irc, I think this could probably be made to work and
> doing a callback would likely give the IOMMU driver the most flexibility
> versus some sort of interface for iommu_iova_to_phys() to return the
> mapping size.
On Mon, 2014-03-17 at 09:30 -0600, Alex Williamson wrote:
>
> I think you've likely already figured out, but it should be stated in
> this thread, yes interfaces do rely on the insane "tell me if you
> unmapped more than I asked for" API.
I'm going to decouple this patch from that question by ad
On Mon, 2014-03-17 at 10:51 -0600, Alex Williamson wrote:
>
> In order to maintain the trivial callback you suggest, the IOTLB would
> need to guarantee that the physical addresses are not accessible prior
> to the callback. Without such a guarantee, we can't unpin the pages and
> the callback wo
and adjust
the 'size' parameter accordingly.
Augment pfn_to_dma_pte() to return the level at which the PTE was found,
which will also be useful later if we end up changing the API for
iommu_iova_to_phys() to behave the same way as is being discussed upstream.
Signed-off-by: David Woodhouse
ge unmaps.
As a side-effect of all these changes, this also fixes the fact that
intel_iommu_unmap() was neglecting to free the page tables for the range
in question after clearing them.
Signed-off-by: David Woodhouse
---
drivers/iommu/intel-iommu.c | 232 +++--
Signed-off-by: David Woodhouse
---
drivers/iommu/intel-iommu.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/drivers/iommu/intel-iommu.c b/drivers/iommu/intel-iommu.c
index f5934fc..c3d4bc9 100644
--- a/drivers/iommu/intel-iommu.c
+++ b/drivers/iommu/intel-iommu.c
not* happen. If there *are* no
IOMMUs in the system which are non-coherent, then we don't need to do
it. And flushing the dcache is a *significant* performance hit.
Signed-off-by: David Woodhouse
---
drivers/iommu/intel-iommu.c | 21 +
1 file changed, 17 insertions(+),
By moving this into get_domain_for_dev() we can make dmar_insert_dev_info()
suitable for use with "special" domains such as the si_domain, which
currently use domain_add_dev_info().
Signed-off-by: David Woodhouse
---
drivers/iommu/intel-io
Signed-off-by: David Woodhouse
---
drivers/iommu/dmar.c | 75
1 file changed, 75 insertions(+)
diff --git a/drivers/iommu/dmar.c b/drivers/iommu/dmar.c
index 34d271e..382f63d 100644
--- a/drivers/iommu/dmar.c
+++ b/drivers/iommu/dmar.c
Signed-off-by: David Woodhouse
---
drivers/iommu/intel-iommu.c | 8 +---
1 file changed, 1 insertion(+), 7 deletions(-)
diff --git a/drivers/iommu/intel-iommu.c b/drivers/iommu/intel-iommu.c
index 3342d65..0751f6d 100644
--- a/drivers/iommu/intel-iommu.c
+++ b/drivers/iommu/intel-iommu.c
Signed-off-by: David Woodhouse
---
drivers/iommu/dmar.c| 1 +
include/linux/intel-iommu.h | 1 +
2 files changed, 2 insertions(+)
diff --git a/drivers/iommu/dmar.c b/drivers/iommu/dmar.c
index 382f63d..cd05a4b 100644
--- a/drivers/iommu/dmar.c
+++ b/drivers/iommu/dmar.c
@@ -952,6 +952,7
Signed-off-by: David Woodhouse
---
drivers/iommu/dmar.c | 22 ++
1 file changed, 10 insertions(+), 12 deletions(-)
diff --git a/drivers/iommu/dmar.c b/drivers/iommu/dmar.c
index eb95020..4c6297d 100644
--- a/drivers/iommu/dmar.c
+++ b/drivers/iommu/dmar.c
@@ -84,7 +84,8
Signed-off-by: David Woodhouse
---
drivers/iommu/intel-iommu.c | 54 +++--
1 file changed, 32 insertions(+), 22 deletions(-)
diff --git a/drivers/iommu/intel-iommu.c b/drivers/iommu/intel-iommu.c
index 85ec773..ccef436 100644
--- a/drivers/iommu/intel
Pass the struct device to it, and also make it return the bus/devfn to use,
since that is also stored in the DMAR table.
Signed-off-by: David Woodhouse
---
drivers/iommu/intel-iommu.c | 78 ++---
1 file changed, 46 insertions(+), 32 deletions(-)
diff
Signed-off-by: David Woodhouse
---
drivers/iommu/intel-iommu.c | 35 +--
1 file changed, 17 insertions(+), 18 deletions(-)
diff --git a/drivers/iommu/intel-iommu.c b/drivers/iommu/intel-iommu.c
index ccef436..1ab7c18 100644
--- a/drivers/iommu/intel-iommu.c
+++ b
Signed-off-by: David Woodhouse
---
drivers/iommu/intel-iommu.c | 47 ++---
1 file changed, 31 insertions(+), 16 deletions(-)
diff --git a/drivers/iommu/intel-iommu.c b/drivers/iommu/intel-iommu.c
index 0751f6d..309ee18 100644
--- a/drivers/iommu/intel
Version 2.2 of the VT-d specification adds support for DMA mapping of ACPI
devices, by adding fields to the DMAR table which indicate the ACPI path
of each DMA-capable device and the PCI bus/dev/fn from which its DMA will
*appear* to come.
The bulk of this patch series is going through the code an
Signed-off-by: David Woodhouse
---
drivers/iommu/intel-iommu.c | 21 ++---
1 file changed, 10 insertions(+), 11 deletions(-)
diff --git a/drivers/iommu/intel-iommu.c b/drivers/iommu/intel-iommu.c
index db7e44b..85ec773 100644
--- a/drivers/iommu/intel-iommu.c
+++ b/drivers/iommu
This was problematic because it works by domain/bus/devfn and we want
to make device_to_iommu() use only a struct device * (for handling non-PCI
devices). Now that the iommu pointer is reliably stored in the
device_domain_info, we don't need to look it up.
Signed-off-by: David Wood
Signed-off-by: David Woodhouse
---
drivers/iommu/intel-iommu.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/iommu/intel-iommu.c b/drivers/iommu/intel-iommu.c
index f38f482..db7e44b 100644
--- a/drivers/iommu/intel-iommu.c
+++ b/drivers/iommu/intel
It's not only for PCI devices any more, and the scope information for an
ACPI device provides the bus and devfn so that has to be stored here too.
Signed-off-by: David Woodhouse
---
drivers/iommu/dmar.c| 41 ++---
drivers/iommu/intel-iommu.c
It's accessible via info->iommu->segment so this is redundant.
Signed-off-by: David Woodhouse
---
drivers/iommu/intel-iommu.c | 17 +++--
1 file changed, 7 insertions(+), 10 deletions(-)
diff --git a/drivers/iommu/intel-iommu.c b/drivers/iommu/intel-iommu.c
index 75ff1
Signed-off-by: David Woodhouse
---
drivers/iommu/intel-iommu.c | 22 +++---
1 file changed, 7 insertions(+), 15 deletions(-)
diff --git a/drivers/iommu/intel-iommu.c b/drivers/iommu/intel-iommu.c
index b50d1d6..3342d65 100644
--- a/drivers/iommu/intel-iommu.c
+++ b/drivers/iommu
Now we store the iommu in the device_domain_info, we don't need to do a
lookup.
Signed-off-by: David Woodhouse
---
drivers/iommu/intel-iommu.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/iommu/intel-iommu.c b/drivers/iommu/intel-iommu.c
index 309ee18..7e
Signed-off-by: David Woodhouse
---
include/acpi/actbl2.h | 15 +--
1 file changed, 13 insertions(+), 2 deletions(-)
diff --git a/include/acpi/actbl2.h b/include/acpi/actbl2.h
index 094a906..da5b057 100644
--- a/include/acpi/actbl2.h
+++ b/include/acpi/actbl2.h
@@ -424,7 +424,8
Signed-off-by: David Woodhouse
---
drivers/iommu/dmar.c | 27 +++
1 file changed, 27 insertions(+)
diff --git a/drivers/iommu/dmar.c b/drivers/iommu/dmar.c
index b19f9f4..eb95020 100644
--- a/drivers/iommu/dmar.c
+++ b/drivers/iommu/dmar.c
@@ -373,6 +373,26 @@ static
Signed-off-by: David Woodhouse
---
drivers/iommu/intel-iommu.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/iommu/intel-iommu.c b/drivers/iommu/intel-iommu.c
index 81f52d3..4a028c9 100644
--- a/drivers/iommu/intel-iommu.c
+++ b/drivers/iommu/intel-iommu.c
Signed-off-by: David Woodhouse
---
drivers/iommu/intel-iommu.c | 12 +---
1 file changed, 5 insertions(+), 7 deletions(-)
diff --git a/drivers/iommu/intel-iommu.c b/drivers/iommu/intel-iommu.c
index 3e15050..7b73c42 100644
--- a/drivers/iommu/intel-iommu.c
+++ b/drivers/iommu/intel
Signed-off-by: David Woodhouse
---
drivers/iommu/intel-iommu.c | 31 +--
1 file changed, 17 insertions(+), 14 deletions(-)
diff --git a/drivers/iommu/intel-iommu.c b/drivers/iommu/intel-iommu.c
index a24611f..741fb1d 100644
--- a/drivers/iommu/intel-iommu.c
+++ b
Signed-off-by: David Woodhouse
---
drivers/iommu/intel-iommu.c | 75 ++---
1 file changed, 36 insertions(+), 39 deletions(-)
diff --git a/drivers/iommu/intel-iommu.c b/drivers/iommu/intel-iommu.c
index 741fb1d..05c5214 100644
--- a/drivers/iommu/intel
Mostly made redundant by using dev_name() instead of pci_name(), and one
instance of using *dev->dma_mask instead of pdev->dma_mask.
Signed-off-by: David Woodhouse
---
drivers/iommu/intel-iommu.c | 12
1 file changed, 4 insertions(+), 8 deletions(-)
diff --git a/drivers
Signed-off-by: David Woodhouse
---
drivers/iommu/intel-iommu.c | 107 +++-
1 file changed, 57 insertions(+), 50 deletions(-)
diff --git a/drivers/iommu/intel-iommu.c b/drivers/iommu/intel-iommu.c
index acb9268..15371ec 100644
--- a/drivers/iommu/intel
Signed-off-by: David Woodhouse
---
drivers/iommu/intel-iommu.c | 26 --
1 file changed, 12 insertions(+), 14 deletions(-)
diff --git a/drivers/iommu/intel-iommu.c b/drivers/iommu/intel-iommu.c
index 15371ec..41eafc3 100644
--- a/drivers/iommu/intel-iommu.c
+++ b/drivers
Signed-off-by: David Woodhouse
---
drivers/iommu/intel-iommu.c | 44 ++--
1 file changed, 22 insertions(+), 22 deletions(-)
diff --git a/drivers/iommu/intel-iommu.c b/drivers/iommu/intel-iommu.c
index cfe08ea..f3c1624 100644
--- a/drivers/iommu/intel
Signed-off-by: David Woodhouse
---
drivers/iommu/intel-iommu.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/iommu/intel-iommu.c b/drivers/iommu/intel-iommu.c
index 7b73c42..9a66bf7 100644
--- a/drivers/iommu/intel-iommu.c
+++ b/drivers/iommu/intel-iommu.c
Should hopefully never happen (RMRRs are an abomination) but while we're
busy eliminating all the PCI assumptions, we might as well do it.
Signed-off-by: David Woodhouse
---
drivers/iommu/intel-iommu.c | 30 ++
1 file changed, 14 insertions(+), 16 deletions(-)
Signed-off-by: David Woodhouse
---
drivers/iommu/intel-iommu.c | 17 -
1 file changed, 8 insertions(+), 9 deletions(-)
diff --git a/drivers/iommu/intel-iommu.c b/drivers/iommu/intel-iommu.c
index 270a25b..3e15050 100644
--- a/drivers/iommu/intel-iommu.c
+++ b/drivers/iommu/intel
Signed-off-by: David Woodhouse
---
drivers/iommu/intel-iommu.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/drivers/iommu/intel-iommu.c b/drivers/iommu/intel-iommu.c
index b1235dc..0f065bc 100644
--- a/drivers/iommu/intel-iommu.c
+++ b/drivers/iommu/intel-iommu.c
@@ -2907,9 +2907,6
Signed-off-by: David Woodhouse
---
drivers/iommu/intel-iommu.c | 61 +++--
1 file changed, 48 insertions(+), 13 deletions(-)
diff --git a/drivers/iommu/intel-iommu.c b/drivers/iommu/intel-iommu.c
index 0f065bc..53996d9 100644
--- a/drivers/iommu/intel
It might not be...
Signed-off-by: David Woodhouse
---
drivers/iommu/intel-iommu.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/iommu/intel-iommu.c b/drivers/iommu/intel-iommu.c
index 9a66bf7..b1235dc 100644
--- a/drivers/iommu/intel-iommu.c
+++ b/drivers/iommu
Signed-off-by: David Woodhouse
---
drivers/iommu/intel-iommu.c | 25 +++--
1 file changed, 11 insertions(+), 14 deletions(-)
diff --git a/drivers/iommu/intel-iommu.c b/drivers/iommu/intel-iommu.c
index f3c1624..270a25b 100644
--- a/drivers/iommu/intel-iommu.c
+++ b/drivers
vers/iommu/intel-iommu.c | 979
-
include/acpi/actbl2.h | 15 +-
include/linux/dmar.h| 18 +-
include/linux/intel-iommu.h | 1 +
5 files changed, 759 insertions(+), 420 deletions(-)
David Woodhouse (37):
iommu/vt-d: Clean up size handling for intel_
> free_domain_mem(domain);
> + domain = NULL;
> goto error;
> }
> free = domain;
Applied; thanks.
--
David WoodhouseOpen Source Technology Centre
david.woodho...@intel.com Intel Cor
On Mon, 2014-03-24 at 15:17 +, David Woodhouse wrote:
> Jörg, please pull into your x86/vt-d branch from
>
> git://git.infradead.org/iommu-2.6
Again, please. A few minor fixes...
Dan Carpenter (1):
iommu/vt-d: returning free pointer in get_domain_for_dev()
David Woo
me scratch page?
That way you avoid the faults, but you also avoid stray DMA to parts of
the system that you don't want to get corrupted.
--
David WoodhouseOpen Source Technology Centre
david.woodho...@intel.com Intel Corporation
sm
hes. That's another case where we need to preserve the
RMRR mapping after the driver takes over — and it *was* working.
--
David WoodhouseOpen Source Technology Centre
david.woodho...@intel.com Intel Corporation
smime.p7s
Description: S/M
plicitly does
precisely that. And call that new function from both intel_unmap_sg()
and intel_unmap_page().
--
David WoodhouseOpen Source Technology Centre
david.woodho...@intel.com Intel Corporation
smime.p7s
Descr
al scratch page.
That way, we allow the "rogue" DMA to continue to the same virtual bus
addresses, but it can only ever affect one piece of physical memory and
can't have detrimental effects elsewhere.
Was that option considered and discounted for some reason? It
On Wed, 2014-05-14 at 13:27 -0600, Alex Williamson wrote:
> The user of the IOMMU API domain expects to have full control of
> the IOVA space for the domain. RMRRs are fundamentally incompatible
> with that idea. We can neither map the RMRR into the IOMMU API
> domain, nor can we guarantee that t
On Wed, 2014-05-21 at 13:05 -0400, Linda Knippers wrote:
>
> > Exactly, I have a hard time bringing myself to care about supporting
> > such devices. Vendors that proliferate RMRR usage need to be aware of
> > the implications of RMRRs for all use cases of a device. First and
> > foremost, we ne
ing the missing flush.
Signed-off-by: David Woodhouse
---
For 3.14 and earlier. As noted, this fix is in 3.15 already.
drivers/iommu/intel-iommu.c | 18 +-
1 file changed, 17 insertions(+), 1 deletion(-)
diff --git a/drivers/iommu/intel-iommu.c b/drivers/iommu/intel-iommu.
macro that's used in both places,
in case the check does get more complicated? Are other devices going to
start getting added to the class of "we don't need the RMRRs to persist
and we *do* want to be able to assign them"... or is that just
needlessly overcomplicating it at thi
instead allow a device driver to call a
'iommu_release_rmrrs()' function once it's reset the hardware to *stop*
doing whatever DMA the BIOS set it up with.
--
David WoodhouseOpen Source Technology Centre
david.woodho...@intel.com
On Tue, 2014-06-17 at 09:15 +0200, Daniel Vetter wrote:
> We've always been struggling with stolen handling, and we've' always
> been struggling with vt-d stuff. Also pass-through seems to be a major
> pain (I've never tried myself). Given all that I'm voting for keeping
> the RMRR and everything e
On Tue, 2014-06-17 at 06:22 -0600, Alex Williamson wrote:
> On Tue, 2014-06-17 at 08:04 +0100, David Woodhouse wrote:
> > On Mon, 2014-06-16 at 23:35 -0600, Alex Williamson wrote:
> > >
> > > Any idea what an off-the-shelf Asus motherboard would be doing with an
On Thu, 2019-02-07 at 10:44 -0800, sathyanarayanan.kuppusw...@linux.intel.com
wrote:
> From: Kuppuswamy Sathyanarayanan
>
> Intel IOMMU Page Request Services (PRS) only works with devices which
> supports/uses PASID. So enable PRI only if the device also enables
> PASID support. For more details
On Thu, 2019-02-07 at 13:09 -0800, Raj, Ashok wrote:
> You are right.. they are completely orthogonal. We just don't have
> a way to handle the page-requests for request without PASID's.
>
> There are some of the vIOMMU work to pass the PRI to who owns
> the device, and we can certainly relax it t
On Thu, 2020-03-26 at 18:11 +0100, Alexander Graf wrote:
> I'm with you on that sentiment, but in the environment I'm currently
> looking at, we have neither DT nor ACPI: The kernel gets purely
> configured via kernel command line. For other unenumerable artifacts on
> the system, such as virtio
On Fri, 2020-05-15 at 10:19 -0700, Raj, Ashok wrote:
> Hi Christoph
>
> On Fri, May 15, 2020 at 08:43:51AM -0700, Christoph Hellwig wrote:
> > Can you please lift the untrusted flag into struct device? It really
> > isn't a PCI specific concept, and we should not have code poking into
> > pci_dev
On Fri, 2012-03-23 at 02:54 +, Hao, Xudong wrote:
> Any other comments for this patch? Or can you check-in it in your
> iommu tree?
Apologies for the delayed response. I've just forwarded this to Linus.
--
dwmw2
smime.p7s
Description: S/MIME cryptographic signature
Now we have four copies of this code, Linus "suggested" it was about time
we stopped copying it and turned it into a helper.
Signed-off-by: David Woodhouse
---
We can still kill a lot more duplication by consolidating the DMA API and
IOMMU API code. The only real difference is that t
g Hao
Signed-off-by: Xiantao Zhang
Acked-by: Chris Wright
Signed-off-by: David Woodhouse
Cc: sta...@kernel.org
---
Resend with a follow-up patch to reduce the duplication of code, as requested.
drivers/iommu/intel-iommu.c | 17 +++--
1 files changed, 11 insertions(+), 6 dele
On Mon, 2012-06-04 at 17:29 -0400, Donald Dutile wrote:
> Intel-iommu initialization doesn't currently reserve the memory used
> for the IOMMU registers. This can allow the pci resource allocator
> to assign a device BAR to the same address as the IOMMU registers.
> This can cause some not so nice
On Mon, 2012-06-04 at 19:09 -0400, Don Dutile wrote:
> > If the BIOS *doesn't* do that, then I believe this should be
> > WARN_TAINT_ONCE(…TAINT_FIRMWARE_WORKAROUND…) like other BIOS problems
> > that we have discovered.
> >
> well, one could argue it may be easier to claim the space reserved in
>
On Wed, 2012-06-06 at 10:16 +0200, Ingo Molnar wrote:
> So basically the patch-set is fine as-is, we just want a
> sufficiently nasty sounding warning message about the BIOS bug,
No. The other change that's required is that the warning and the
workaround need to trigger even when IOMMU support i
On Wed, 2012-06-06 at 10:29 +0200, Ingo Molnar wrote:
> So for all practical purposes we get 99% of the warning power
> without going into chicken-and-egg problems like how do we
> determine that there's an IOMMU area there if there's no IOMMU
> aware code in the kernel, right?
That's not a ch
On Thu, 2012-09-27 at 15:34 -0600, Alex Williamson wrote:
> It really seems like RMRRs are incompatible with IOMMU API use though.
> If an RMRR is setup for a VM domain, that's bad because a) it gives the
> VM direct access to that range of host memory, and b) it interferes with
> the guest use of
On Fri, 2012-09-28 at 11:46 +0200, Joerg Roedel wrote:
> Even on modern hardware with modern (IOMMU aware) kernels there is still
> this small time window when the OS has enabled the IOMMU and the USB
> driver is not initialized yet. In this time window the RMRR memory
> region is still necessary,
HP may have been shipping such things 'for a while' but it's never actually
worked right, yes? This thread is about the patch that's intended to *fix* that?
If they could just manage to make their firmware-owned DMA appear to be from a
different PCIe device/function from the one the OS gets to
On Fri, 2012-09-28 at 12:36 -0400, Linda Knippers wrote:
> I can only speak to the HP servers. We have been shipping devices
> 'for a while' that provide sensor-type data to the platform. The
> device does DMA writes to a range of memory (the RMRR) and
> iLO does DMA reads of that data.
>
> This
On Mon, 2014-08-25 at 12:11 +, Sathya Perla wrote:
>
> Hi Wang, from the kernel log I can see that the faulting address
> 0xbdf7 falls in the
> RMRR range the BIOS requested:
> [0.111343] DMAR: RMRR base: 0x00bdf6f000 end: 0x00bdf7efff
We can't see which *devices* that RMRR wa
)', which is perfectly
sufficient and arguably how it should have been done in the first place.
I had an almost identical patch last week for internal testing, because
I stupidly hadn't noticed that Jiang had beaten me to it.
Acked-By: David Woodhouse
> > This issue was introd
hare at the moment, the
> patches might be useful for the others in the meantime and I wouldn't mind
> having them in upstream either.
Acked-By: David Woodhouse for all 4, with
the caveat that I don't actually want to see various IOMMU drivers
*using* the IOVA code directly.
Where poss
1 - 100 of 305 matches
Mail list logo
