On 10/09/2019 08:31 AM, Bjorn Helgaas wrote:
On Tue, Oct 08, 2019 at 06:06:46PM -0400, Don Dutile wrote:
On 10/08/2019 05:38 PM, Bjorn Helgaas wrote:
On Thu, Oct 03, 2019 at 05:10:07PM -0500, Bjorn Helgaas wrote:
On Thu, Oct 03, 2019 at 11:04:45AM +0200, CREGUT Pierre IMT/OLN wrote
On 10/08/2019 05:38 PM, Bjorn Helgaas wrote:
On Thu, Oct 03, 2019 at 05:10:07PM -0500, Bjorn Helgaas wrote:
On Thu, Oct 03, 2019 at 11:04:45AM +0200, CREGUT Pierre IMT/OLN wrote:
...
NIC drivers send netlink events when their state change, but it is
the core that changes the value of num_vfs
On 09/05/2019 02:32 AM, Kelsey Skunberg wrote:
sriov_numvfs and sriov_drivers_autoprobe have "unusual" permissions (0664)
with no reported or found reason for allowing group write permissions.
libvirt runs as root when dealing with PCI, and chowns files for qemu
needs. There is not a need for the
On 09/04/2019 02:22 AM, Kelsey Skunberg wrote:
On Thu, Aug 15, 2019 at 10:37:13AM -0400, Don Dutile wrote:
On 08/14/2019 01:38 AM, Bjorn Helgaas wrote:
[+cc Bodong, Don, Greg for permission question]
On Tue, Aug 13, 2019 at 02:45:12PM -0600, Kelsey Skunberg wrote:
Symbolic permissions such
On 09/04/2019 02:22 AM, Kelsey Skunberg wrote:
On Thu, Aug 15, 2019 at 10:37:13AM -0400, Don Dutile wrote:
On 08/14/2019 01:38 AM, Bjorn Helgaas wrote:
[+cc Bodong, Don, Greg for permission question]
On Tue, Aug 13, 2019 at 02:45:12PM -0600, Kelsey Skunberg wrote:
Symbolic permissions such
On 08/15/2019 11:33 AM, Kelsey Skunberg wrote:
This series is designed to clean up device attributes and permissions in
pci-sysfs.c. Then move the sysfs SR-IOV functions from pci-sysfs.c to
iov.c for better organization.
Patch 1: Define device attributes with DEVICE_ATTR* instead of __ATTR*.
Pa
On 08/14/2019 01:38 AM, Bjorn Helgaas wrote:
[+cc Bodong, Don, Greg for permission question]
On Tue, Aug 13, 2019 at 02:45:12PM -0600, Kelsey Skunberg wrote:
Symbolic permissions such as "(S_IWUSR | S_IWGRP)" are not
preferred and octal permissions should be used instead. Change all
symbolic pe
On 05/09/2018 08:44 AM, Stephen Bates wrote:
Hi Don
RDMA VFs lend themselves to NVMEoF w/device-assignment need a way to
put NVME 'resources' into an assignable/manageable object for
'IOMMU-grouping',
which is really a 'DMA security domain' and less an 'IOMMU grouping domain'.
On 05/08/2018 05:27 PM, Stephen Bates wrote:
Hi Don
Well, p2p DMA is a function of a cooperating 'agent' somewhere above the two
devices.
That agent should 'request' to the kernel that ACS be removed/circumvented
(p2p enabled) btwn two endpoints.
I recommend doing so via a sysfs meth
On 05/09/2018 10:44 AM, Alex Williamson wrote:
On Wed, 9 May 2018 12:35:56 +
"Stephen Bates" wrote:
Hi Alex and Don
Correct, the VM has no concept of the host's IOMMU groups, only
the hypervisor knows about the groups,
But as I understand it these groups are usually passed through
On 05/08/2018 08:01 PM, Alex Williamson wrote:
On Tue, 8 May 2018 19:06:17 -0400
Don Dutile wrote:
On 05/08/2018 05:27 PM, Stephen Bates wrote:
As I understand it VMs need to know because VFIO passes IOMMU
grouping up into the VMs. So if a IOMMU grouping changes the VM's
view of its
On 05/08/2018 05:27 PM, Stephen Bates wrote:
Hi Don
Well, p2p DMA is a function of a cooperating 'agent' somewhere above the two
devices.
That agent should 'request' to the kernel that ACS be removed/circumvented
(p2p enabled) btwn two endpoints.
I recommend doing so via a sysfs meth
On 05/08/2018 06:03 PM, Alex Williamson wrote:
On Tue, 8 May 2018 21:42:27 +
"Stephen Bates" wrote:
Hi Alex
But it would be a much easier proposal to disable ACS when the
IOMMU is not enabled, ACS has no real purpose in that case.
I guess one issue I have with this is that it disa
On 05/08/2018 12:57 PM, Alex Williamson wrote:
On Mon, 7 May 2018 18:23:46 -0500
Bjorn Helgaas wrote:
On Mon, Apr 23, 2018 at 05:30:32PM -0600, Logan Gunthorpe wrote:
Hi Everyone,
Here's v4 of our series to introduce P2P based copy offload to NVMe
fabrics. This version has been rebased onto
On 05/08/2018 10:44 AM, Stephen Bates wrote:
Hi Dan
It seems unwieldy that this is a compile time option and not a runtime
option. Can't we have a kernel command line option to opt-in to this
behavior rather than require a wholly separate kernel image?
I think because of the se
On 04/21/2018 04:34 PM, Bjorn Helgaas wrote:
On Fri, Apr 20, 2018 at 12:28:08PM -0400, Alexander Duyck wrote:
This series is meant to add support for SR-IOV on devices when the VFs are
not managed by the kernel. Examples of recent patches attempting to do this
include:
virto - https://patchwork.
On 03/15/2018 02:40 PM, Alexander Duyck wrote:
This series is meant to add support for SR-IOV on devices when the VFs are
not managed by the kernel. Examples of recent patches attempting to do this
include:
virto - https://patchwork.kernel.org/patch/10241225/
pci-stub - https://patchwork.kernel.o
On 03/13/2018 11:04 AM, David Woodhouse wrote:
On Tue, 2018-03-13 at 07:51 -0700, Alexander Duyck wrote:
Actually the suggestion I had from Don Dutile was that we should be
looking at creating a pci-stub like driver specifically for those type
of devices, but without the ability to arbitrarily
On 03/05/2018 04:41 PM, Alexander Duyck wrote:
On Mon, Mar 5, 2018 at 12:57 PM, Don Dutile wrote:
On 03/01/2018 03:22 PM, Alex Williamson wrote:
On Wed, 28 Feb 2018 16:36:38 -0800
Alexander Duyck wrote:
On Wed, Feb 28, 2018 at 2:59 PM, Alex Williamson
wrote:
On Wed, 28 Feb 2018 09:49
On 03/01/2018 03:22 PM, Alex Williamson wrote:
On Wed, 28 Feb 2018 16:36:38 -0800
Alexander Duyck wrote:
On Wed, Feb 28, 2018 at 2:59 PM, Alex Williamson
wrote:
On Wed, 28 Feb 2018 09:49:21 -0800
Alexander Duyck wrote:
On Tue, Feb 27, 2018 at 2:25 PM, Alexander Duyck
wrote:
On Tue, Fe
On 10/02/2017 03:10 PM, David Woodhouse wrote:
On Mon, 2017-10-02 at 14:52 -0400, Don Dutile wrote:
On 10/02/2017 08:35 AM, David Woodhouse wrote:
This would allow you to enable SR-IOV on a PF before its driver is
loaded, right? Even when that driver *is* going to need to perform
resource
On 10/02/2017 08:35 AM, David Woodhouse wrote:
On Thu, 2017-09-28 at 12:56 -0400, Don Dutile wrote:
Well, my point is more like: why put it in uio?
why not make it available via pcie, setup while/if no driver attached?
i.e., other non-uio users can use the mechanism like libvirt? ...
if a
On 09/28/2017 11:52 AM, David Woodhouse wrote:
On Thu, 2017-09-28 at 11:05 -0400, Don Dutile wrote:
ah, nickel summary: no in-kernel driver w/.sriov-configure method.
if so, now I'm up to speed with you
h
so, that would imply we need an in-kernel, pcie-common, .sriov-
conf
On 09/28/2017 09:46 AM, David Woodhouse wrote:
On Thu, 2017-09-28 at 08:22 -0400, Don Dutile wrote:
After reading Alex's response, I now understand Dave's question
better and why the patch won't work in general.
UIO doesn't work "in general". It requires a ve
On 09/27/2017 07:06 PM, Alexander Duyck wrote:
On Wed, Sep 27, 2017 at 3:20 PM, David Woodhouse wrote:
On Wed, 2017-09-27 at 17:00 -0500, Bjorn Helgaas wrote:
IIUC, this question is basically "why doesn't the PCI core enable IOV
automatically when it sees an IOV-capable device?"
I think one
On 09/27/2017 06:00 PM, Bjorn Helgaas wrote:
[+cc Don, Alex D, Alex W, Bryant, Bodong, Michael, kvm list]
On Wed, Sep 27, 2017 at 01:59:22PM +0100, David Woodhouse wrote:
From: David Woodhouse
Allow userspace to configure SR-IOV VFs through sysfs.
Currently, we need an in-kernel driver to pe
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/14/2016 06:56 AM, Johannes Thumshirn wrote:
On Wed, Nov 09, 2016 at 11:11:40AM -0600, Bjorn Helgaas wrote:
Hi Johannes,
On Wed, Nov 02, 2016 at 04:35:52PM -0600, Johannes Thumshirn wrote:
The Read Completion Boundary (RCB) bit must only be set on a device or
endpoint if it is set on the
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
;
, "linux-kernel@vger.kernel.org"
, Don Dutile
On 01/14/2015 12:00 PM, Mark Rutland wrote:
On Wed, Jan 14, 2015 at 12:47:00AM +, Jon Masters wrote:
Hi Folks,
TLDR: I would like to consider the value of adding something like
"cluster_siblings" or similar in sysfs to d
On 04/29/2016 11:37 AM, Richard W.M. Jones wrote:
On Fri, Apr 29, 2016 at 08:16:35AM -0700, Greg KH wrote:
On Fri, Apr 29, 2016 at 09:10:06AM +0100, Richard W.M. Jones wrote:
On Thu, Apr 28, 2016 at 03:56:33PM -0700, Greg KH wrote:
On Thu, Apr 28, 2016 at 11:18:33PM +0100, Richard W.M. Jones w
On 05/26/2015 05:11 PM, Alex Williamson wrote:
v2: don't modify entry->id.device
In most cases we only use ARI with SR-IOV VFs, which do not support
INTx and therefore never hit this problem. However, some non-SR-IOV
implementations create multiple PFs, extending beyond the standard
3-bit funct
On 05/26/2015 04:42 PM, Alex Williamson wrote:
On Tue, 2015-05-26 at 16:06 -0400, Don Dutile wrote:
On 05/26/2015 01:54 PM, Alex Williamson wrote:
The PCIe specification, rev 3.0, section 2.2.8.1, contains the
following implementation note:
Virtual Wire Mapping for INTx Interrupts From
On 05/26/2015 01:54 PM, Alex Williamson wrote:
The PCIe specification, rev 3.0, section 2.2.8.1, contains the
following implementation note:
Virtual Wire Mapping for INTx Interrupts From ARI Devices
The implied Device Number for an ARI Device is 0. When ARI-aware
software (includ
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
Vlasenko
Cc: Marek Szyprowski
Cc: Konrad Rzeszutek Wilk
Cc: David Woodhouse
Cc: Don Dutile
Cc: Thomas Gleixner
Cc: Ingo Molnar
Cc: "H. Peter Anvin"
Cc: Andi Kleen
Cc: x...@kernel.org
Cc: linux-kernel@vger.kernel.org
---
Changes in v2: added EXPORT_SYMBOL()
Changes in v3: adde
On 01/14/2015 06:24 AM, Arnd Bergmann wrote:
On Tuesday 13 January 2015 19:47:00 Jon Masters wrote:
Hi Folks,
TLDR: I would like to consider the value of adding something like
"cluster_siblings" or similar in sysfs to describe ARM topology.
A quick question on intended data representation in /
On 01/13/2015 07:47 PM, Jon Masters wrote:
Hi Folks,
TLDR: I would like to consider the value of adding something like
"cluster_siblings" or similar in sysfs to describe ARM topology.
A quick question on intended data representation in /sysfs topology
before I ask the team on this end to go dow
On 05/28/2014 04:14 PM, Bjorn Helgaas wrote:
On Wed, May 28, 2014 at 10:39 AM, Alexander Duyck
wrote:
On 05/27/2014 09:12 PM, Alex Williamson wrote:
On Tue, 2014-05-27 at 19:19 -0600, Bjorn Helgaas wrote:
Maybe resetting the PF should just fail if there's an active VF. If
you need to reset
On 04/28/2014 05:51 AM, AKASHI Takahiro wrote:
Hi Don,
Sorry for not responding to you soon:
been there, done that! .. no problem..
On 04/12/2014 06:37 AM, Don Dutile wrote:
On 03/15/2014 01:49 AM, AKASHI Takahiro wrote:
(Please apply this patch after my ftrace patch to resolve some
On 03/15/2014 01:49 AM, AKASHI Takahiro wrote:
(Please apply this patch after my ftrace patch to resolve some conflict
on arm64/kernel/ptrace.c, functionally it doesn't depend on ftrace though)
This patchset adds system call audit support on arm64.
Both 32-bit (AUDIT_ARCH_ARM) and 64-bit tasks (
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: io...@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 08/01/2013 05:41 PM, Alex Williamson wrote:
On Thu, 2013-08-01 at 17:29 -0400, Don Dutile wrote:
On 08/01/2013 12:55 PM, Alex Williamson wrote:
The PCI spec indicates that with stable power, reset needs to be
asserted for a minimum of 1ms (Trst). Seems like we should be able
to assume
On 08/01/2013 12:55 PM, Alex Williamson wrote:
The PCI spec indicates that with stable power, reset needs to be
asserted for a minimum of 1ms (Trst). Seems like we should be able
to assume power is stable for a runtime secondary bus reset. The
current code has always used 100ms with no explanat
On 08/01/2013 12:55 PM, Alex Williamson wrote:
Sometimes pci_reset_function is not sufficient. We have cases where
devices do not support any kind of reset, but there might be multiple
functions on the bus preventing pci_reset_function from doing a
secondary bus reset. We also have cases where
On 08/01/2013 12:55 PM, Alex Williamson wrote:
Only cosmetic changes to existing paths.
Signed-off-by: Alex Williamson
---
drivers/pci/pci.c | 52 +++-
1 file changed, 35 insertions(+), 17 deletions(-)
diff --git a/drivers/pci/pci.c b/drivers
On 06/26/2013 03:03 PM, Alex Williamson wrote:
On Mon, 2013-06-24 at 11:43 -0600, Bjorn Helgaas wrote:
On Wed, Jun 19, 2013 at 6:43 AM, Don Dutile wrote:
On 06/18/2013 10:52 PM, Bjorn Helgaas wrote:
On Tue, Jun 18, 2013 at 5:03 PM, Don Dutile wrote:
On 06/18/2013 06:22 PM, Alex
early quirk so that the chip devices/revisions
specified in the above update are also covered in the same way:
Signed-off-by: Neil Horman
Reviewed-by: Jan Beulich
CC: Jan Beulich
CC: Joerg Roedel
CC: Andrew Cooper
CC: Malcolm Crossley
CC: Prarit Bhargava
CC: Don Zickus
CC: Don Dutile
CC: Thomas
On 07/08/2013 12:17 PM, Alex Williamson wrote:
Ping. Comments?
As I read the PCIe & SRIOV specs wrt ACS, this patch set appears
to fix the nuances we have learned about whether a device (MFD or bridge)
implements (the equiv. of) ACS, or not, as required (for secure, device
assignment).
Like t
On 07/11/2013 09:38 PM, Yijing Wang wrote:
Hi Don,
Thanks for your review and comments very much!
+dev->sn = pci_device_serial_number(dev);
+
Finally, 'the comment below':
I know you were following Bjorn's suggestion, which I thought
was an improvement, but why not do above assignment
On 07/11/2013 04:09 PM, Bjorn Helgaas wrote:
On Thu, Jul 11, 2013 at 3:51 AM, Don Dutile wrote:
On 07/11/2013 05:43 AM, Yijing Wang wrote:
Introduce PCIe Ext Capability Device Serial Number support,
so we can use the unique device serial number to identify
the physical device. During system
Sorry, did a 'reply' instead of 'reply all' on first reply to this patch...
excuse any repeat...
- Don
On 07/11/2013 05:43 AM, Yijing Wang wrote:
If device was removed from slot and reinsert a new device during
suspend, pciehp can not identify the physical device change now.
So the old driver .r
On 07/11/2013 05:43 AM, Yijing Wang wrote:
Introduce PCIe Ext Capability Device Serial Number support,
so we can use the unique device serial number to identify
the physical device. During system suspend, if the PCIe
device was removed and inserted a new same device, after
system resume there is
early quirk so that the chip devices/revisions
specified in the above update are also covered in the same way:
Signed-off-by: Neil Horman
Reviewed-by: Jan Beulich
CC: Jan Beulich
CC: Joerg Roedel
CC: Andrew Cooper
CC: Malcolm Crossley
CC: Prarit Bhargava
CC: Don Zickus
CC: Don Dutile
CC: Thomas
On 06/18/2013 10:52 PM, Bjorn Helgaas wrote:
On Tue, Jun 18, 2013 at 5:03 PM, Don Dutile wrote:
On 06/18/2013 06:22 PM, Alex Williamson wrote:
On Tue, 2013-06-18 at 15:31 -0600, Bjorn Helgaas wrote:
On Tue, Jun 18, 2013 at 12:20 PM, Alex Williamson
wrote:
On Tue, 2013-06-18 at 11:28
On 06/18/2013 06:22 PM, Alex Williamson wrote:
On Tue, 2013-06-18 at 15:31 -0600, Bjorn Helgaas wrote:
On Tue, Jun 18, 2013 at 12:20 PM, Alex Williamson
wrote:
On Tue, 2013-06-18 at 11:28 -0600, Bjorn Helgaas wrote:
On Thu, May 30, 2013 at 12:40:19PM -0600, Alex Williamson wrote:
PCIe ACS (
On 06/17/2013 04:20 PM, Bjorn Helgaas wrote:
On Sun, May 26, 2013 at 11:53:14PM +0800, 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: i
On 05/30/2013 02:40 PM, Alex Williamson wrote:
PCIe ACS (Access Control Services) is the PCIe 2.0+ feature that
allows us to control whether transactions are allowed to be redirected
in various subnodes of a PCIe topology. For instance, if two
endpoints are below a root port or downsteam switch
On 05/23/2013 08:35 PM, Li, Zhen-Hua wrote:
In Intel Vt-D specs, Chapter 9.3 Page-Table Entry,
The size of ADDR(address) field is 12:51, but the function dma_pte_addr
treats it as 12:63.
Signed-off-by: Li, Zhen-Hua
---
drivers/iommu/intel-iommu.c |4 ++--
include/linux/dma_remapping.h
On 06/11/2013 07:19 PM, Sumner, William wrote:
(2013/06/11 11:20), Bjorn Helgaas wrote:
On Fri, Jun 7, 2013 at 2:46 AM, Takao Indoh wrote:
(2013/06/07 13:14), Bjorn Helgaas wrote:
One thing I'm not sure about is that you are only resetting PCIe
devices, but I don't think the problem is ac
On 05/30/2013 02:37 PM, Alex Williamson wrote:
Downstream ports support for all ACS flags supercedes multifunction
exclusion of some flags. The PCIe spec also fully specifies which
PCIe types are subject to the multifunction rules and excludes event
collectors and PCIe-to-PCI bridges entirely.
:30:32PM -0400, Don Dutile wrote:
On 05/14/2013 05:39 PM, Alexander Duyck wrote:
On 05/14/2013 12:59 PM, Yinghai Lu wrote:
On Tue, May 14, 2013 at 12:45 PM, Alexander Duyck
wrote:
On 05/14/2013 11:44 AM, Yinghai Lu wrote:
On Tue, May 14, 2013 at 9:00 AM, Alexander Duyck
wrote:
I'm
On 05/21/2013 05:58 PM, Alexander Duyck wrote:
On 05/21/2013 02:31 PM, Don Dutile wrote:
On 05/21/2013 05:30 PM, Don Dutile wrote:
On 05/14/2013 05:39 PM, Alexander Duyck wrote:
On 05/14/2013 12:59 PM, Yinghai Lu wrote:
On Tue, May 14, 2013 at 12:45 PM, Alexander Duyck
wrote:
On 05/14
On 05/21/2013 05:30 PM, Don Dutile wrote:
On 05/14/2013 05:39 PM, Alexander Duyck wrote:
On 05/14/2013 12:59 PM, Yinghai Lu wrote:
On Tue, May 14, 2013 at 12:45 PM, Alexander Duyck
wrote:
On 05/14/2013 11:44 AM, Yinghai Lu wrote:
On Tue, May 14, 2013 at 9:00 AM, Alexander Duyck
wrote:
I&#
On 05/14/2013 05:39 PM, Alexander Duyck wrote:
On 05/14/2013 12:59 PM, Yinghai Lu wrote:
On Tue, May 14, 2013 at 12:45 PM, Alexander Duyck
wrote:
On 05/14/2013 11:44 AM, Yinghai Lu wrote:
On Tue, May 14, 2013 at 9:00 AM, Alexander Duyck
wrote:
I'm sorry, but what is the point of this patc
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: io...@lists.linux-foundation.org
Cc: linux-kernel@vger.kernel.org
On 05/07/2013 10:57 PM, Alex Williamson wrote:
Move the secondary bus reset code from pci_parent_bus_reset() into its own
function. Export it as we'll later be calling it from hotplug controllers.
Signed-off-by: Alex Williamson
---
drivers/pci/pci.c | 32 +++-
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?
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: io...@lists.linux-foundation.org; linux-kernel@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/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/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
lease see:
https://bugzilla.redhat.com/show_bug.cgi?id=887006
Signed-off-by: Neil Horman
CC: Prarit Bhargava
CC: Don Zickus
CC: Don Dutile
CC: Bjorn Helgaas
CC: Asit Mallick
CC: David Woodhouse
CC: linux-...@vger.kernel.org
CC: Joerg Roedel
CC: Konrad Rzeszutek Wilk
CC: Arkadiusz Miśkiewicz
---
C
On 04/05/2013 09:55 PM, Bjorn Helgaas wrote:
On Fri, Apr 5, 2013 at 1:31 PM, Neil Horman wrote:
A few years back intel published a spec update:
http://www.intel.com/content/dam/doc/specification-update/5520-and-5500-chipset-ioh-specification-update.pdf
For the 5520 and 5500 chipsets which cont
oblem.
Signed-off-by: Neil Horman
CC: Prarit Bhargava
CC: Don Zickus
CC: Don Dutile
CC: Bjorn Helgaas
CC: Asit Mallick
CC: David Woodhouse
CC: linux-...@vger.kernel.org
---
Change notes:
v2)
* Moved the quirk to the x86 arch, since consensus seems to be that the 55XX
chipset series is x86 only. I de
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/17/2013 06:28 PM, Alex Williamson wrote:
On Sun, 2013-03-17 at 08:33 -0600, Myron Stowe wrote:
On Sun, 2013-03-17 at 07:38 -0600, Alex Williamson wrote:
On Sat, 2013-03-16 at 22:36 -0700, Greg KH wrote:
On Sat, Mar 16, 2013 at 10:11:22PM -0600, Alex Williamson wrote:
On Sat, 2013-03-16
hem a reminder that their systems are vulnurable to this problem.
Signed-off-by: Neil Horman
CC: Prarit Bhargava
CC: Don Zickus
CC: Don Dutile
CC: Bjorn Helgaas
CC: Asit Mallick
CC: linux-...@vger.kernel.org
Ping, anyone want to Ack/Nack this?
Don's comment earlier seems to imply that this
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
1 - 100 of 136 matches
Mail list logo
