1 Hi Don,
2 It seems that we agree in the area of keeping the iommu active and
using it to
3 isolate the legacy DMA. We also agree that the device's IO driver
should be
4 the software that deals with the device (e.g.: resets it, etc.)
5
6 It also seems that
1 Hi Don,
2 It seems that we agree in the area of keeping the iommu active and
using it to
3 isolate the legacy DMA. We also agree that the device's IO driver
should be
4 the software that deals with the device (e.g.: resets it, etc.)
5
6 It also seems that
Resending as plain-text.
Bill
From: Sumner, William
Sent: Wednesday, March 12, 2014 11:15 AM
To: 'Vivek Goyal'
Cc: dw...@infradead.org; indou.ta...@jp.fujitsu.com; b...@redhat.com;
j...@8bytes.org; linux-...@vger.kernel.org; ke...@lists.infradead.org;
alex.william...@redhat.com; linux-kernel
Resending as plain-text.
Bill
From: Sumner, William
Sent: Wednesday, March 12, 2014 11:15 AM
To: 'Vivek Goyal'
Cc: dw...@infradead.org; indou.ta...@jp.fujitsu.com; b...@redhat.com;
j...@8bytes.org; linux-...@vger.kernel.org; ke...@lists.infradead.org;
alex.william...@redhat.com; linux-kernel
On Tue 3/4/2014 8:59 AM, Joerg Roedel wrote
>On Fri, Jan 10, 2014 at 03:07:29PM -0700, Bill Sumner wrote:
>> +context_get_entry(struct context_entry *context_addr,
>> +struct intel_iommu *iommu, u32 bus, int devfn) {
>> +unsigned long long q; /* quadword scratch
Hi Joerg,
On Tue 3/4/2014 9:06 AM, Joerg Roedel wrote:
>
>On Fri, Jan 10, 2014 at 03:07:26PM -0700, Bill Sumner wrote:
>> Bill Sumner (6):
>> Crashdump-Accepting-Active-IOMMU-Flags-and-Prototype
>> Crashdump-Accepting-Active-IOMMU-Utility-functions
>>
Hi Joerg,
On Tue 3/4/2014 9:06 AM, Joerg Roedel wrote:
On Fri, Jan 10, 2014 at 03:07:26PM -0700, Bill Sumner wrote:
Bill Sumner (6):
Crashdump-Accepting-Active-IOMMU-Flags-and-Prototype
Crashdump-Accepting-Active-IOMMU-Utility-functions
On Tue 3/4/2014 8:59 AM, Joerg Roedel wrote
On Fri, Jan 10, 2014 at 03:07:29PM -0700, Bill Sumner wrote:
+context_get_entry(struct context_entry *context_addr,
+struct intel_iommu *iommu, u32 bus, int devfn) {
+unsigned long long q; /* quadword scratch */
+
Vivek, Ben, Eric,
Please take a look at a proposed patch to intel-iommu: "[PATCHv3 0/6] Crashdump
Accepting Active IOMMU"
This is specifically for kdump; however, would some small variation of this
technique be applicable to kexec ?
Thanks,
Bill
-Original Message-
From: kexec
Vivek, Ben, Eric,
Please take a look at a proposed patch to intel-iommu: [PATCHv3 0/6] Crashdump
Accepting Active IOMMU
This is specifically for kdump; however, would some small variation of this
technique be applicable to kexec ?
Thanks,
Bill
-Original Message-
From: kexec
addr and ppap->page_size is eventually added to the
tree (either when a new range is started or when ppap->last is set.)
Bill
-Original Message-----
From: Baoquan He [mailto:b...@redhat.com]
Sent: Friday, December 20, 2013 12:04 AM
To: Sumner, William
Cc: dw...@infradead.org; indo
is set.)
Bill
-Original Message-
From: Baoquan He [mailto:b...@redhat.com]
Sent: Friday, December 20, 2013 12:04 AM
To: Sumner, William
Cc: dw...@infradead.org; indou.ta...@jp.fujitsu.com;
io...@lists.linux-foundation.org; ke...@lists.infradead.org;
alex.william...@redhat.com; linux
e submitting them.
Bill
-Original Message-
From: Takao Indoh [mailto:indou.ta...@jp.fujitsu.com]
Sent: Tuesday, November 12, 2013 12:45 AM
To: Sumner, William; bhelg...@google.com; alex.william...@redhat.com;
ddut...@redhat.com
Cc: linux-...@vger.kernel.org; ke...@lists.infradead.org;
linux-
...@jp.fujitsu.com]
Sent: Tuesday, November 12, 2013 12:45 AM
To: Sumner, William; bhelg...@google.com; alex.william...@redhat.com;
ddut...@redhat.com
Cc: linux-...@vger.kernel.org; ke...@lists.infradead.org;
linux-kernel@vger.kernel.org; io...@lists.linux-foundation.org;
ishii.hiron...@jp.fujitsu.com
A while ago we discussed the concept of the crashdump kernel dealing with the
legacy DMA from the (old) panic'd kernel by allowing the (new) crashdump
kernel: to accept the iommu hardware in an active state, to leave the current
translations in-place so that legacy DMA will continue using its
A while ago we discussed the concept of the crashdump kernel dealing with the
legacy DMA from the (old) panic'd kernel by allowing the (new) crashdump
kernel: to accept the iommu hardware in an active state, to leave the current
translations in-place so that legacy DMA will continue using its
>(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 actually specific to PCIe,
(2013/06/11 11:20), Bjorn Helgaas wrote:
On Fri, Jun 7, 2013 at 2:46 AM, Takao Indoh indou.ta...@jp.fujitsu.com
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 actually specific to
hods to reset the PCI device. Would any of
these be useful additions to the proposed patch ?
Bill Sumner
-Original Message-
From: Takao Indoh [mailto:indou.ta...@jp.fujitsu.com]
Sent: Tuesday, May 07, 2013 2:10 AM
To: Sumner, William
Cc: linux-...@vger.kernel.org; ke...@lists.infradead.org;
linux-
additions to the proposed patch ?
Bill Sumner
-Original Message-
From: Takao Indoh [mailto:indou.ta...@jp.fujitsu.com]
Sent: Tuesday, May 07, 2013 2:10 AM
To: Sumner, William
Cc: linux-...@vger.kernel.org; ke...@lists.infradead.org;
linux-kernel@vger.kernel.org; tin...@gmail.com;
io
I have installed your original patch set (from last November) and tested with
three platforms, each with a different IO configuration. On the first platform
crashdumps were consistently successful. On the second and third platforms,
the reset of one specific PCI device on each platform (a
I have installed your original patch set (from last November) and tested with
three platforms, each with a different IO configuration. On the first platform
crashdumps were consistently successful. On the second and third platforms,
the reset of one specific PCI device on each platform (a
22 matches
Mail list logo
