Re: Multitude of resource assignment functions

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Sun, Jun 30, 2019 at 12:58 PM Nicholas Johnson
<nicholas.johnson-opensource@xxxxxxxxxxxxxx> wrote:
>
> *snip*
>
> Some other related thoughts:

> - Should pci=noacpi imply pci=nocrs? It does not appear to, and I feel
> like it should, as CRS is part of ACPI and relates to PCI.

Are you sure about that? There has been explicit support for CRS in
the PCIe Base spec since gen1.

> - Modern arches could give this option by default if they want
> everything done by the OS. Although this would not be nearly as nice as
> a code overhaul or branching out pci into pci-old and pci-new.

This is only really nice if you can use the new code 100% of the time.
If we're keeping around the old code then it's still going to be a
maintenance burden since there's no shortage of platforms with odd
firmware requirements.

> - I have not given iommu or intel_iommu parameters but I am getting DMAR
> faults (probably because I am using pci=noacpi) but normally the DMAR
> does not come on if you do not ask it to. Is there perhaps something
> recently added to do with Thunderbolt that is activating it? I
> understand that regardless, DMAR does not work well without ACPI. The
> main two I care about are DMAR and MADT (multiple processors) tables and
> otherwise, I would disable ACPI altogether.

IIRC the IOMMU can be forced on for anything behind a thunderbolt
controller since external devices aren't necessarily trustworthy. You
might be hitting that.

>
> Cheers,
> Nicholas



[Index of Archives]     [DMA Engine]     [Linux Coverity]     [Linux USB]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [Greybus]

  Powered by Linux