On Tue, 2015-06-23 at 16:06 +0200, Joerg Roedel wrote:
> On Tue, Jun 23, 2015 at 02:31:30PM +0100, David Woodhouse wrote:
> > However, it's still fairly gratuitous for all non-broken hardware, and
> > will tend to hide hardware and driver bugs during testing of new
> > hardware.
> >
> > I'd much rather see this limited to a blacklist of known-broken
> > devices, an accompanied by a kernel message along the lines of
> >
> > 'Preserving VT-d page tables for broken HP device xxxx:xxxx'
> >
> > For *any* device which isn't so broken that it craps itself on taking
> > a DMA fault and cannot be reset, this page table copy shouldn't be
> > needed, right?
>
> In theory yes, but as it came to my mind recently, there is this BIOS
> "value-add" called APEI (ACPI Platform Error Interface) which has a
> 'Firmware first' mode.
>
> So when this is active the firmware handles any errors happening in the
> system and reports them to the OS with a severity it can decide on its
> own.
>
> Such errors could be DMA target aborts, for example. And I have seen
> systems where at least rejected interrupt requests were reported to the
> OS as fatal errors, causing a kernel panic in Linux. But the firmware is
> also free to report ordinary DMA failures as fatal errors, who knows...

Yay for BIOS value subtract.

The thing is, this would be utterly broken. The IOMMU is supposed to
protect us from rogue devices. In this hypothetical scenario, a device
can bring the entire system down and we have no chance to isolate it
and recover. It means that assigning devices to guests should be
*disallowed* because it can't be done securely.

On this kind of system, we might as well turn off the IOMMU entirely as
in a lot of respects, it's only making things *worse*.

> So while you are right that these changes might hide hardware and driver
> bugs, I think it is still the best to try avoiding such faults at all
> costs in the kdump kernel to actually get a dump, even if the device
> would actually be able to recover from the master abort.

How about an *option* to do it for all devices (which in turn can
perhaps be triggered by a system-level blacklist for things like APEI,
or perhaps just a system DMI match on "HP").

--
dwmw2

Attachments:

smime.p7s (5.56 kB)

2015-06-25 06:37:32

by Li, ZhenHua

[permalink] [raw]

Subject: Re: [PATCH 00/19] Fix Intel IOMMU breakage in kdump kernel

On 06/23/2015 10:38 PM, David Woodhouse wrote:
> On Tue, 2015-06-23 at 16:06 +0200, Joerg Roedel wrote:
>> On Tue, Jun 23, 2015 at 02:31:30PM +0100, David Woodhouse wrote:
>>> However, it's still fairly gratuitous for all non-broken hardware, and
>>> will tend to hide hardware and driver bugs during testing of new
>>> hardware.
>>>
>>> I'd much rather see this limited to a blacklist of known-broken
>>> devices, an accompanied by a kernel message along the lines of
>>>
>>> 'Preserving VT-d page tables for broken HP device xxxx:xxxx'
>>>
>>> For *any* device which isn't so broken that it craps itself on taking
>>> a DMA fault and cannot be reset, this page table copy shouldn't be
>>> needed, right?
>>
>> In theory yes, but as it came to my mind recently, there is this BIOS
>> "value-add" called APEI (ACPI Platform Error Interface) which has a
>> 'Firmware first' mode.
>>
>> So when this is active the firmware handles any errors happening in the
>> system and reports them to the OS with a severity it can decide on its
>> own.
>>
>> Such errors could be DMA target aborts, for example. And I have seen
>> systems where at least rejected interrupt requests were reported to the
>> OS as fatal errors, causing a kernel panic in Linux. But the firmware is
>> also free to report ordinary DMA failures as fatal errors, who knows...
>
> Yay for BIOS value subtract.
>
> The thing is, this would be utterly broken. The IOMMU is supposed to
> protect us from rogue devices. In this hypothetical scenario, a device
> can bring the entire system down and we have no chance to isolate it
> and recover. It means that assigning devices to guests should be
> *disallowed* because it can't be done securely.
>
> On this kind of system, we might as well turn off the IOMMU entirely as
> in a lot of respects, it's only making things *worse*.
>
>> So while you are right that these changes might hide hardware and driver
>> bugs, I think it is still the best to try avoiding such faults at all
>> costs in the kdump kernel to actually get a dump, even if the device
>> would actually be able to recover from the master abort.
>
> How about an *option* to do it for all devices (which in turn can
> perhaps be triggered by a system-level blacklist for things like APEI,
> or perhaps just a system DMI match on "HP").
>
Hi David,
It is a bad idea to check the DMI match on "HP". Though I have not see
any similar problems on other systems, I believe there are. Also not
all HP systems have such problem.
I agree with a blacklist for devices.

Thanks
Zhenhua

2015-06-25 06:41:59

by Li, ZhenHua

[permalink] [raw]

Subject: Re: [PATCH 00/19] Fix Intel IOMMU breakage in kdump kernel

Hi all,
I see Joerg has backported it to sles12 in the commoent of novel
bugzilla 856382, so I will only backport it to redhat el.

Thanks
Zhenhua

On 06/13/2015 02:47 PM, Joerg Roedel wrote:
> Hi,
>
> as David Woodhouse pointed out, my fixes and cleanups for
> the original patch-set turned out to be a complete rewrite.
> So to have a cleaner history of the feature and to make
> backporting easier, here is a rewrite of my changes based on
> v4.1-rc7.
>
> Some additional issues have been fixed by this rewrite, like
> a kdump-kernel boot panic with 'iommu=pt' and support for
> copying the extended root-entry and context table formats
> has been added.
>
> I plan to rebuild the x86/vt-d branch of the iommu tree with
> these patches.
>
> Regards,
>
> Joerg
>
> Joerg Roedel (19):
> iommu/vt-d: Cleanup log messages
> iommu/vt-d: Init QI before root entry is allocated
> iommu/vt-d: Make root entry visible for hardware right after
> allocation
> iommu/vt-d: Detect pre enabled translation
> iommu/vt-d: Copy translation tables from old kernel
> iommu/vt-d: Do not re-use domain-ids from the old kernel
> iommu/vt-d: Mark copied context entries
> iommu/vt-d: Allocate si_domain in init_dmars()
> iommu/vt-d: Don't do early domain assignment if kdump kernel
> iommu/vt-d: Don't copy translation tables if RTT bit needs to be
> changed
> iommu/vt-d: Don't disable translation prior to OS handover
> iommu/vt-d: Enable Translation only if it was previously disabled
> iommu/vt-d: Move EIM detection to intel_prepare_irq_remapping
> iommu/vt-d: Move QI initializationt to intel_setup_irq_remapping
> iommu/vt-d: Disable IRQ remapping in intel_prepare_irq_remapping
> iommu/vt-d: Set IRTA in intel_setup_irq_remapping
> iommu/vt-d: Copy IR table from old kernel when in kdump mode
> iommu/vt-d: Make sure copied over IR entries are not reused
> iommu/vt-d: Don't disable IR when it was previously enabled
>
> drivers/iommu/dmar.c | 28 +-
> drivers/iommu/intel-iommu.c | 495 ++++++++++++++++++++++++++++--------
> drivers/iommu/intel_irq_remapping.c | 255 ++++++++++++-------
> include/linux/intel-iommu.h | 5 +
> 4 files changed, 573 insertions(+), 210 deletions(-)
>

2015-06-25 08:06:59

by David Woodhouse

[permalink] [raw]

Subject: Re: [PATCH 00/19] Fix Intel IOMMU breakage in kdump kernel

On Thu, 2015-06-25 at 14:35 +0800, Li, ZhenHua wrote:
> Hi David,
> It is a bad idea to check the DMI match on "HP". Though I have not see
> any similar problems on other systems, I believe there are. Also not
> all HP systems have such problem.

Yeah, the HP suggestion was a little tongue-in-cheek. Although it does
seem to be HP who is the main offender in this area — both the BIOS
"value subtract" and the habit of doing utterly insane things with the
IOMMU.

> I agree with a blacklist for devices.

Do you have a list of the problematic ones? I think a blacklist *and*
an option to enable it for all devices might be the best solution.

--
dwmw2