On 5/11/21 12:12 PM, Logan Gunthorpe wrote:
On 2021-05-11 10:05 a.m., Don Dutile wrote:
On 5/1/21 11:58 PM, John Hubbard wrote:
On 4/8/21 10:01 AM, Logan Gunthorpe wrote:
In order to call upstream_bridge_distance_warn() from a dma_map function,
it must not sleep. The only reason it does
On 4/8/21 1:01 PM, Logan Gunthorpe wrote:
pci_p2pdma_map_type() will be needed by the dma-iommu map_sg
implementation because it will need to determine the mapping type
ahead of actually doing the mapping to create the actual iommu mapping.
Signed-off-by: Logan Gunthorpe
---
drivers/pci/p2pdm
On 4/8/21 1:01 PM, Logan Gunthorpe wrote:
When a PCI P2PDMA page is seen, set the IOVA length of the segment
to zero so that it is not mapped into the IOVA. Then, in finalise_sg(),
apply the appropriate bus address to the segment. The IOVA is not
created if the scatterlist only consists of P2PDMA
On 4/8/21 1:01 PM, Logan Gunthorpe wrote:
Add a flags member to the dma_map_ops structure with one flag to
indicate support for PCI P2PDMA.
Also, add a helper to check if a device supports PCI P2PDMA.
Signed-off-by: Logan Gunthorpe
---
include/linux/dma-map-ops.h | 3 +++
include/linux/dma
On 4/8/21 1:01 PM, Logan Gunthorpe wrote:
dma_map_sg() either returns a positive number indicating the number
of entries mapped or zero indicating that resources were not available
to create the mapping. When zero is returned, it is always safe to retry
the mapping later once resources have been
On 5/2/21 3:58 PM, John Hubbard wrote:
On 4/8/21 10:01 AM, Logan Gunthorpe wrote:
Attempt to find the mapping type for P2PDMA pages on the first
DMA map attempt if it has not been done ahead of time.
Previously, the mapping type was expected to be calculated ahead of
time, but if pages are to c
On 5/2/21 1:35 AM, John Hubbard wrote:
On 4/8/21 10:01 AM, Logan Gunthorpe wrote:
In order to use upstream_bridge_distance_warn() from a dma_map function,
it must not sleep. However, pci_get_slot() takes the pci_bus_sem so it
might sleep.
In order to avoid this, try to get the host bridge's dev
On 4/8/21 1:01 PM, Logan Gunthorpe wrote:
In order to use upstream_bridge_distance_warn() from a dma_map function,
it must not sleep. However, pci_get_slot() takes the pci_bus_sem so it
might sleep.
In order to avoid this, try to get the host bridge's device from
bus->self, and if that is not se
On 5/1/21 11:58 PM, John Hubbard wrote:
On 4/8/21 10:01 AM, Logan Gunthorpe wrote:
In order to call upstream_bridge_distance_warn() from a dma_map function,
it must not sleep. The only reason it does sleep is to allocate the seqbuf
to print which devices are within the ACS path.
Switch the kmal
On 4/8/21 1:01 PM, Logan Gunthorpe wrote:
Hi,
This patchset continues my work to to add P2PDMA support to the common
dma map operations. This allows for creating SGLs that have both P2PDMA
and regular pages which is a necessary step to allowing P2PDMA pages in
userspace.
The earlier RFC[1] gene
On 12/08/2016 04:36 AM, Auger Eric wrote:
Hi,
On 15/11/2016 14:09, Eric Auger wrote:
Following LPC discussions, we now report reserved regions through
iommu-group sysfs reserved_regions attribute file.
While I am respinning this series into v4, here is a tentative summary
of technical topics
On 11/21/2016 12:13 AM, Jon Masters wrote:
On 11/07/2016 07:45 PM, Will Deacon wrote:
I figured this was a reasonable post to piggy-back on for the LPC minutes
relating to guest MSIs on arm64.
Thanks for this Will. I'm still digging out post-LPC and SC16, but the
summary was much appreciated,
On 11/11/2016 10:50 AM, Alex Williamson wrote:
On Fri, 11 Nov 2016 12:19:44 +0100
Joerg Roedel wrote:
On Thu, Nov 10, 2016 at 10:46:01AM -0700, Alex Williamson wrote:
In the case of x86, we know that DMA mappings overlapping the MSI
doorbells won't be translated correctly, it's not a valid ma
On 11/11/2016 06:19 AM, Joerg Roedel wrote:
On Thu, Nov 10, 2016 at 10:46:01AM -0700, Alex Williamson wrote:
In the case of x86, we know that DMA mappings overlapping the MSI
doorbells won't be translated correctly, it's not a valid mapping for
that range, and therefore the iommu driver backing
On 11/09/2016 12:03 PM, Will Deacon wrote:
On Tue, Nov 08, 2016 at 09:52:33PM -0500, Don Dutile wrote:
On 11/08/2016 06:35 PM, Alex Williamson wrote:
On Tue, 8 Nov 2016 21:29:22 +0100
Christoffer Dall wrote:
Is my understanding correct, that you need to tell userspace about the
location of
On 11/08/2016 06:35 PM, Alex Williamson wrote:
On Tue, 8 Nov 2016 21:29:22 +0100
Christoffer Dall wrote:
Hi Will,
On Tue, Nov 08, 2016 at 02:45:59AM +, Will Deacon wrote:
Hi all,
I figured this was a reasonable post to piggy-back on for the LPC minutes
relating to guest MSIs on arm64.
On 11/08/2016 12:54 PM, Will Deacon wrote:
On Tue, Nov 08, 2016 at 03:27:23PM +0100, Auger Eric wrote:
On 08/11/2016 03:45, Will Deacon wrote:
Rather than treat these as separate problems, a better interface is to
tell userspace about a set of reserved regions, and have this include
the MSI doo
On 11/07/2016 09:45 PM, Will Deacon wrote:
Hi all,
I figured this was a reasonable post to piggy-back on for the LPC minutes
relating to guest MSIs on arm64.
On Thu, Nov 03, 2016 at 10:02:05PM -0600, Alex Williamson wrote:
We can always have QEMU reject hot-adding the device if the reserved
re
On 07/27/2015 06:27 PM, Bjorn Helgaas wrote:
Hi Don,
On Mon, Jul 27, 2015 at 10:00:53AM -0400, Don Dutile wrote:
On 07/20/2015 08:15 PM, Bjorn Helgaas wrote:
Stop caching the Invalidate Queue Depth in struct pci_dev.
pci_ats_queue_depth() is typically called only once per device, and it
On 07/20/2015 08:15 PM, Bjorn Helgaas wrote:
Stop caching the Invalidate Queue Depth in struct pci_dev.
pci_ats_queue_depth() is typically called only once per device, and it
returns a fixed value per-device, so callers who need the value frequently
can cache it themselves.
Signed-off-by: Bjorn
On 05/07/2015 02:11 PM, Jerome Glisse wrote:
On Thu, May 07, 2015 at 12:16:30PM -0500, Bjorn Helgaas wrote:
On Thu, May 7, 2015 at 11:23 AM, William Davis wrote:
From: Bjorn Helgaas [mailto:bhelg...@google.com]
Sent: Thursday, May 7, 2015 8:13 AM
To: Yijing Wang
Cc: William Davis; Joerg Roedel
On 05/07/2015 09:21 PM, Dave Young wrote:
On 05/07/15 at 10:25am, Don Dutile wrote:
On 05/07/2015 10:00 AM, Dave Young wrote:
On 04/07/15 at 10:12am, Don Dutile wrote:
On 04/06/2015 11:46 PM, Dave Young wrote:
On 04/05/15 at 09:54am, Baoquan He wrote:
On 04/03/15 at 05:21pm, Dave Young
On 05/07/2015 10:00 AM, Dave Young wrote:
On 04/07/15 at 10:12am, Don Dutile wrote:
On 04/06/2015 11:46 PM, Dave Young wrote:
On 04/05/15 at 09:54am, Baoquan He wrote:
On 04/03/15 at 05:21pm, Dave Young wrote:
On 04/03/15 at 05:01pm, Li, ZhenHua wrote:
Hi Dave,
There may be some
On 05/07/2015 10:00 AM, Dave Young wrote:
On 04/07/15 at 10:12am, Don Dutile wrote:
On 04/06/2015 11:46 PM, Dave Young wrote:
On 04/05/15 at 09:54am, Baoquan He wrote:
On 04/03/15 at 05:21pm, Dave Young wrote:
On 04/03/15 at 05:01pm, Li, ZhenHua wrote:
Hi Dave,
There may be some
On 05/04/2015 07:05 AM, Joerg Roedel wrote:
On Fri, Apr 03, 2015 at 04:40:31PM +0800, Dave Young wrote:
Have not read all the patches, but I have a question, not sure this
has been answered before. Old memory is not reliable, what if the old
memory get corrupted before panic? Is it safe to conti
On 04/06/2015 11:46 PM, Dave Young wrote:
On 04/05/15 at 09:54am, Baoquan He wrote:
On 04/03/15 at 05:21pm, Dave Young wrote:
On 04/03/15 at 05:01pm, Li, ZhenHua wrote:
Hi Dave,
There may be some possibilities that the old iommu data is corrupted by
some other modules. Currently we do not hav
On 12/15/2014 11:55 AM, Suman Tripathi wrote:
This patch adds the support for the APM X-Gene SoC AHBC IOMMU driver.
Signed-off-by: Suman Tripathi
---
Suman Tripathi (3):
xgene-ahbc-iommu: Add support for APM X-Gene SoC AHBC IOMMU driver.
arm64: dts: Add the APM X-Gene AHBC IOMMU DTS node
On 04/08/2014 12:14 PM, David Woodhouse wrote:
On Mon, 2014-04-07 at 16:43 -0400, Don Dutile wrote:
Additionally, a tidbit of information like "some servers force NMI's
on DMAR faults,
and cause a system reset, thereby, preventing a kdump to occur"
should have been included a
On 01/10/2014 05:07 PM, Bill Sumner wrote:
v2->v3:
1. Commented-out "#define DEBUG 1" to eliminate debug messages
2. Updated the comments about changes in each version in all patches in the set.
3. Fixed: one-line added to Copy-Translations" patch to initialize the iovad
struct as reco
On 01/20/2014 11:21 AM, Alex Williamson wrote:
On Mon, 2014-01-20 at 14:45 +, Varun Sethi wrote:
-Original Message-
From: Alex Williamson [mailto:alex.william...@redhat.com]
Sent: Saturday, January 18, 2014 2:06 AM
To: Sethi Varun-B16395
Cc: iommu@lists.linux-foundation.org; linux-
On 11/21/2013 03:21 AM, Yijing Wang wrote:
This is the v2 patch, the v1 link:
http://marc.info/?l=linux-pci&m=138364004628824&w=2
v1->v2: keep (pci_dev *) pointer array in dmar_drhd_uni, only use pci device id
to update pci_dev * pointer info during device hotplug in intel
iomm
On 10/29/2013 07:47 AM, Alex Williamson wrote:
On Mon, 2013-10-28 at 21:29 -0400, Don Dutile wrote:
On 09/30/2013 11:37 AM, Bhushan Bharat-R65777 wrote:
-Original Message-
From: iommu-boun...@lists.linux-foundation.org [mailto:iommu-
boun...@lists.linux-foundation.org] On Behalf Of
On 09/30/2013 11:37 AM, Bhushan Bharat-R65777 wrote:
-Original Message-
From: iommu-boun...@lists.linux-foundation.org [mailto:iommu-
boun...@lists.linux-foundation.org] On Behalf Of Antonios Motakis
Sent: Monday, September 30, 2013 8:59 PM
To: kvm...@lists.cs.columbia.edu; alex.willia
On 10/02/2013 08:14 AM, Alexander Graf wrote:
On 01.10.2013, at 21:21, Yoder Stuart-B08248 wrote:
static int __init vfio_iommu_type1_init(void)
{
- if (!iommu_present(&pci_bus_type))
+#ifdef CONFIG_PCI
+ if (iommu_present(&pci_bus_type)) {
+ iommu_bus_type =&pci_bus_t
On 07/24/2013 05:22 PM, Alex Williamson wrote:
On Wed, 2013-07-24 at 16:42 -0400, Don Dutile wrote:
On 07/23/2013 06:35 PM, Bjorn Helgaas wrote:
On Thu, Jul 11, 2013 at 03:03:27PM -0600, Alex Williamson wrote:
This provides interfaces for drivers to discover the visible PCIe
requester ID for
On 06/03/2013 05:58 PM, Benoît Canet wrote:
When the PF does an FLR the hardware go back to its default state, the SR-IOV
configuration is gone and the VFs disappears from the bus.
Then the restore state function of the kernel reset code would bring the SR-IOV
PF configuration back.
Ok, now you
On 06/03/2013 05:27 PM, Benoît Canet wrote:
I was asking this because the PF driver should reset the PF while the VF are
used by VFIO/QEMU when the PF doesn't respond anymore.
What your VF does while your PF is being reset is PF (& VF) dependent.
A 'good design' would not impact the VF operati
On 06/03/2013 03:29 PM, Benoît Canet wrote:
to a guest will the consequences of a PF FLR be handled fine by QEMU and the
guest ?
the reset occurs long before the device is passed to the guest.
I was asking this because the PF driver should reset the PF while the VF are
used by VFIO/QEMU when
On 06/03/2013 02:02 PM, Alex Williamson wrote:
On Mon, 2013-06-03 at 18:33 +0200, Benoît Canet wrote:
Hello,
I plan to write a PF driver for an SR-IOV card and make the VFs work with QEMU's
VFIO passthrough so I am asking the following design question before trying to
write and push code.
Afte
On 06/01/2013 08:13 AM, Benoît Canet wrote:
Hello,
I may have soon the PF driver of an SR-IOV card to code and make work with
QEMU/KVM so I have the following questions.
In an AMD64 setup where QEMU use VFIO to passthrough the VFs of an SR-IOV card
to a guest will the consequences of a PF FLR
On 05/14/2013 12:52 PM, Jiang Liu wrote:
Enhance iommu drviers to use hotplug-safe iterators to walk
PCI buses.
Signed-off-by: Jiang Liu
Cc: Joerg Roedel
Cc: Ingo Molnar
Cc: Donald Dutile
Cc: Hannes Reinecke
Cc: "Li, Zhen-Hua"
Cc: iommu@lists.linux-foundation.org
Cc: linux-ker...@vger.kernel.org
On 05/07/2013 12:39 PM, Alex Williamson wrote:
On Wed, 2013-04-24 at 13:58 +0900, Takao Indoh wrote:
This patch resets PCIe devices on boot to stop ongoing DMA. When
"pci=pcie_reset_devices" is specified, a hot reset is triggered on each
PCIe root port and downstream port to reset its downstream
ep(1000);
As Linus pointed out in an earlier patch, msleep() after each device
is s-l-o-w and unnecessary; should do a single msleep(1000) after
*all* the command registers are written. That way, the added delay is 1sec,
not 1sec*ndevs.
q: is this turning off command register for only PCI(e) endpoints?
On 05/02/2013 10:13 AM, Yan Burman wrote:
-Original Message-
From: Michael S. Tsirkin [mailto:m...@redhat.com]
Sent: Thursday, May 02, 2013 04:56
To: Or Gerlitz
Cc: Roland Dreier; iommu@lists.linux-foundation.org; Yan Burman; linux-
r...@vger.kernel.org
Subject: Re: decent performance
On 04/30/2013 05:15 PM, Alex Williamson wrote:
On Tue, 2013-04-30 at 16:48 -0400, Don Dutile wrote:
On 04/30/2013 03:11 PM, Konrad Rzeszutek Wilk wrote:
Does vfio work with swiotlb and if not, can/should swiotlb be
extended? Or does the time and space overhead make it a moot point?
It does
On 04/30/2013 03:11 PM, Konrad Rzeszutek Wilk wrote:
Does vfio work with swiotlb and if not, can/should swiotlb be
extended? Or does the time and space overhead make it a moot point?
It does not work with SWIOTLB as it uses the DMA API, not the IOMMU API.
I think you got it reversed. vfio us
On 04/30/2013 01:28 PM, Konrad Rzeszutek Wilk wrote:
On Sat, Apr 27, 2013 at 12:22:28PM +0800, Andrew Cooks wrote:
On Fri, Apr 26, 2013 at 6:23 AM, Don Dutile wrote:
On 04/24/2013 10:49 PM, Sethi Varun-B16395 wrote:
-Original Message-
From: iommu-boun...@lists.linux
On 04/30/2013 01:28 PM, Konrad Rzeszutek Wilk wrote:
On Sat, Apr 27, 2013 at 12:22:28PM +0800, Andrew Cooks wrote:
On Fri, Apr 26, 2013 at 6:23 AM, Don Dutile wrote:
On 04/24/2013 10:49 PM, Sethi Varun-B16395 wrote:
-Original Message-
From: iommu-boun...@lists.linux
hat adding some of the steps from this algorithm to one of the already proposed patches
would avoid the hang that I saw on two platforms.
Bill Sumner
-Original Message-
From: kexec [mailto:kexec-boun...@lists.infradead.org] On Behalf Of Don Dutile
Sent: Friday, April 26, 2013
On 04/30/2013 10:56 AM, Suravee Suthikulanit wrote:
On 4/29/2013 4:42 PM, Don Dutile wrote:
On 04/29/2013 04:34 PM, Duran, Leo wrote:
I'm wondering if resetting the IOMMU at init-time (once) would clear any BIOS
induced noise.
Leo
Well, depends what you mean by 'reset'
(a
On 04/30/2013 10:49 AM, Suravee Suthikulanit wrote:
On 4/29/2013 3:10 PM, Don Dutile wrote:
On 04/29/2013 03:45 PM, Suravee Suthikulanit wrote:
Joerg,
We are in the process of implementing AMD IOMMU error handling, and I would
like some comments from you and the community.
Currently, the
mailto:iommu-
boun...@lists.linux-foundation.org] On Behalf Of Don Dutile
Sent: Monday, April 29, 2013 3:10 PM
To: Suthikulpanit, Suravee
Cc: iommu@lists.linux-foundation.org; linux-ker...@vger.kernel.org
Subject: Re: RFC: IOMMU/AMD: Error Handling
On 04/29/2013 03:45 PM, Suravee Suthikulanit wrote
On 04/29/2013 03:45 PM, Suravee Suthikulanit wrote:
Joerg,
We are in the process of implementing AMD IOMMU error handling, and I would
like some comments from you and the community.
Currently, the AMD IOMMU driver only reports events from the event log in the
dmesg, and does not try to handle
On 04/25/2013 11:10 PM, Takao Indoh wrote:
> (2013/04/26 3:01), Don Dutile wrote:
>> On 04/25/2013 01:11 AM, Takao Indoh wrote:
>>> (2013/04/25 4:59), Don Dutile wrote:
>>>> On 04/24/2013 12:58 AM, Takao Indoh wrote:
>>>>> This patch resets PCIe devices
On 04/24/2013 10:49 PM, Sethi Varun-B16395 wrote:
-Original Message-
From: iommu-boun...@lists.linux-foundation.org [mailto:iommu-
boun...@lists.linux-foundation.org] On Behalf Of Don Dutile
Sent: Thursday, April 25, 2013 1:11 AM
To: Alex Williamson
Cc: Yoder Stuart-B08248; iommu
On 04/25/2013 01:11 AM, Takao Indoh wrote:
> (2013/04/25 4:59), Don Dutile wrote:
>> On 04/24/2013 12:58 AM, Takao Indoh wrote:
>>> This patch resets PCIe devices on boot to stop ongoing DMA. When
>>> "pci=pcie_reset_devices" is specified, a hot reset is tri
On 04/24/2013 12:58 AM, Takao Indoh wrote:
This patch resets PCIe devices on boot to stop ongoing DMA. When
"pci=pcie_reset_devices" is specified, a hot reset is triggered on each
PCIe root port and downstream port to reset its downstream endpoint.
Problem:
This patch solves the problem that kdu
On 04/23/2013 03:47 PM, Alex Williamson wrote:
On Tue, 2013-04-23 at 19:16 +, Yoder Stuart-B08248 wrote:
-Original Message-
From: Alex Williamson [mailto:alex.william...@redhat.com]
Sent: Tuesday, April 23, 2013 11:56 AM
To: Yoder Stuart-B08248
Cc: Joerg Roedel; iommu@lists.linux-f
On 04/24/2013 06:46 AM, Joerg Roedel wrote:
On Tue, Apr 23, 2013 at 09:22:45AM -0400, Don Dutile wrote:
Given other threads on this mail list (and I've seen crashes with same problem)
where this type of logging during a flood of IOMMU errors will lock up the
machine,
is there something
On 04/18/2013 12:28 PM, Joerg Roedel wrote:
On Thu, Apr 18, 2013 at 11:13:19AM -0500, Suravee Suthikulanit wrote:
This workaround is required for both event log and ppr log. Your
patch is only taking care of the event log.
Right, thanks for the notice. Here is the updated patch.
From cebe04
I agree that unsigned long was an improper choice for iova's,
but why aren't they dma_addr_t ? ... an iova is a dma-addr, just
a 'virtual' one wrt phys-addr.
On 03/22/2013 06:34 PM, Varun Sethi wrote:
This is required in case of PAMU, as it can support a window size of up
to 64G (even on 32bit).
On 03/25/2013 10:28 AM, Alex Williamson wrote:
On Mon, 2013-03-25 at 10:23 +1100, Alexey Kardashevskiy wrote:
As IOMMU groups are exposed to the user space by their numbers,
the user space can use them in various kernel APIs so the kernel
might need an API to find a group by its ID.
As an examp
On 03/07/2013 01:31 PM, Don Dutile wrote:
cc-ing the upstream iommu-list
On 03/05/2013 09:43 PM, Li, Zhen-Hua wrote:
The number of dma fault reasons in intel's document are from 1 to 0xD, but in
dmar.c I cannot find fault reason 0xD.
In this document:
Intel Virtualization Technolog
cc-ing the upstream iommu-list
On 03/05/2013 09:43 PM, Li, Zhen-Hua wrote:
The number of dma fault reasons in intel's document are from 1 to 0xD, but in
dmar.c I cannot find fault reason 0xD.
In this document:
Intel Virtualization Technology for Directed I/O Architecture Specification
http://d
On 11/20/2012 02:43 PM, Tom Mingarelli wrote:
This patch is to prevent non-USB devices that have RMRRs associated with them
from
being placed into the SI Domain during init. This fixes the issue where the
RMRR info
for devices being placed in and out of the SI Domain gets lost.
Signed-off-by:
On 11/13/2012 10:38 AM, Alex Williamson wrote:
On Mon, 2012-11-12 at 15:05 -0600, Matthew Thode wrote:
On 11/12/2012 01:57 PM, Don Dutile wrote:
On 11/12/2012 04:26 AM, Doug Goldstein wrote:
On Sun, Nov 11, 2012 at 5:19 PM, Matthew Thode
wrote:
System boots with vt-d disabled in bios
On 11/12/2012 04:26 AM, Doug Goldstein wrote:
On Sun, Nov 11, 2012 at 5:19 PM, Matthew Thode
wrote:
System boots with vt-d disabled in bios. Otherwise I get the errors in
the attached log. I can do whatever testing you need as this system is
not in production yet. gonna paste the important p
On 09/18/2012 12:49 PM, Tom Mingarelli wrote:
When a 32bit PCI device is removed from the SI Domain, the RMRR information
for this device becomes invalid and needs to be reprocessed to avoid DMA
Read errors. These errors are evidenced by the Present bit being cleared in
the device's context entry
On 09/18/2012 07:59 AM, Joerg Roedel wrote:
On Wed, Sep 12, 2012 at 03:55:05PM -0400, Donald Dutile wrote:
This patch was posted back in Nov 2011:
http://lists.linuxfoundation.org/pipermail/iommu/2011-November/003086.html
and due to discussion about the patch, it was never pulled in.
Althoug
For those on the iommu list that are not on
the devel-drivers or lkml list
Since failures/bugs in drivers using dma mapping API
result in IOMMU detected failures (faults) or IOMMU resource leakage...
Original Message
Subject: [RFC] DMA mapping error check analysis
Date: F
On 06/04/2012 07:23 PM, David Woodhouse wrote:
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 m
On 06/04/2012 06:37 PM, David Woodhouse wrote:
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 r
On 06/04/2012 06:15 PM, Joe Perches wrote:
On Mon, 2012-06-04 at 17:29 -0400, Donald Dutile wrote:
Replace printk(KERN_* with pr_*() functions.
Please add
#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
before any include and remove the embedded PREFIX
from each printk
diff --git a/drivers/iomm
On 05/30/2012 04:19 PM, Alex Williamson wrote:
Work around broken devices and adhere to ACS support when determining
IOMMU grouping.
Signed-off-by: Alex Williamson
---
drivers/iommu/intel-iommu.c | 25 +
1 file changed, 25 insertions(+)
diff --git a/drivers/iommu/i
On 05/24/2012 06:46 PM, Alex Williamson wrote:
On Thu, 2012-05-24 at 17:38 -0400, Don Dutile wrote:
On 05/22/2012 01:05 AM, Alex Williamson wrote:
x86 is probably the wrong name for this VFIO IOMMU driver, but x86
is the primary target for it. This driver support a very simple
usage model
On 05/22/2012 01:04 AM, Alex Williamson wrote:
Version 2 incorporating acks and feedback from v1. The PCI DMA quirk
and ACS check are reworked, sysfs iommu groups ABI Documentation
added as well as numerous other fixes, including patches from Alexey
Kardashevskiy towards supporting POWER usage o
On 05/22/2012 01:05 AM, Alex Williamson wrote:
Fill in many missing definitions and add sizeof fields for many
sections allowing for more extensive config parsing.
Signed-off-by: Alex Williamson
---
overall, i'm very glad to see defines instead of hardcoded numbers in the code,
but
in
On 05/22/2012 01:05 AM, Alex Williamson wrote:
x86 is probably the wrong name for this VFIO IOMMU driver, but x86
is the primary target for it. This driver support a very simple
usage model using the existing IOMMU API. The IOMMU is expected to
support the full host address space with no specia
On 05/22/2012 01:05 AM, Alex Williamson wrote:
In a PCI environment, transactions aren't always required to reach
the root bus before being re-routed. Intermediate switches between
an endpoint and the root bus can redirect DMA back downstream before
things like IOMMUs have a chance to intervene.
On 05/22/2012 01:04 AM, Alex Williamson wrote:
Add back group support for AMD& Intel. amd_iommu already tracks
devices and has init and uninit routines to manage groups.
intel-iommu does this on the fly, so we make use of the notifier
support built into iommu groups to create and remove groups.
On 05/21/2012 10:59 AM, Alex Williamson wrote:
On Mon, 2012-05-21 at 09:31 -0400, Don Dutile wrote:
On 05/18/2012 10:47 PM, Alex Williamson wrote:
On Fri, 2012-05-18 at 19:00 -0400, Don Dutile wrote:
On 05/18/2012 06:02 PM, Alex Williamson wrote:
On Wed, 2012-05-16 at 09:29 -0400, Don Dutile
On 05/18/2012 10:47 PM, Alex Williamson wrote:
On Fri, 2012-05-18 at 19:00 -0400, Don Dutile wrote:
On 05/18/2012 06:02 PM, Alex Williamson wrote:
On Wed, 2012-05-16 at 09:29 -0400, Don Dutile wrote:
On 05/15/2012 05:09 PM, Alex Williamson wrote:
On Tue, 2012-05-15 at 13:56 -0600, Bjorn
On 05/18/2012 06:02 PM, Alex Williamson wrote:
On Wed, 2012-05-16 at 09:29 -0400, Don Dutile wrote:
On 05/15/2012 05:09 PM, Alex Williamson wrote:
On Tue, 2012-05-15 at 13:56 -0600, Bjorn Helgaas wrote:
On Mon, May 14, 2012 at 4:49 PM, Alex Williamson
wrote:
On Mon, 2012-05-14 at 16:02
On 05/15/2012 05:09 PM, Alex Williamson wrote:
On Tue, 2012-05-15 at 13:56 -0600, Bjorn Helgaas wrote:
On Mon, May 14, 2012 at 4:49 PM, Alex Williamson
wrote:
On Mon, 2012-05-14 at 16:02 -0600, Bjorn Helgaas wrote:
On Fri, May 11, 2012 at 4:56 PM, Alex Williamson
wrote:
In a PCIe environm
On 04/05/2012 04:58 PM, Chris Wright wrote:
* Donald Dutile (ddut...@redhat.com) wrote:
--- a/drivers/iommu/dmar.c
+++ b/drivers/iommu/dmar.c
@@ -581,7 +581,7 @@ int __init detect_intel_iommu(void)
int alloc_iommu(struct dmar_drhd_unit *drhd)
{
struct intel_iommu *iommu;
- int
self-nak.
Found an iounmap() with a missing release_mem_region();
will post V2 shortly.
On 03/08/2012 06:51 PM, 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
On 01/30/2012 03:59 PM, Andrew Morton wrote:
(switched to email. Please respond via emailed reply-to-all, not via the
bugzilla web interface).
On Sat, 28 Jan 2012 17:55:38 GMT
bugzilla-dae...@bugzilla.kernel.org wrote:
https://bugzilla.kernel.org/show_bug.cgi?id=42679
I don't know if this
87 matches
Mail list logo
