lkml.org 
[lkml]   [2009]   [Apr]   [7]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [GIT *] intel-iommu updates for 2.6.30 (second batch)

    * David Woodhouse <dwmw2@infradead.org> wrote:

    > > The patch below fixes it, but it is only an ugly workaround: we
    > > really dont want 'depends on ACPI' dependencies to spread like
    > > that.
    >
    > It _does_ depend on ACPI. Much as I wish it didn't, it's
    > fundamentally tied to it for now.
    >
    > > ACPI is a hardware discovery mechanism. It might be the only way
    > > to discover these pieces of hardware at the moment, but we
    > > should not tie method of discovery to hardware support. I'd
    > > suggest a dmar_acpi.c splitout of the ACPI bits.
    >
    > As I said, DMAR is the name of an ACPI table. If we ever manage
    > to get non-ACPI discovery of the hardware, we can write new code
    > which mentions _neither_ DMAR nor ACPI. And at that point, we can
    > talk about moving any generic parts out of the existing 'dmar.c'.
    > Perhaps into intel-iommu.c?

    Yeah - i kept thinking of dmar.c as being mostly about discovery
    unrelated, genuine hardware support: QI, msi bits / fault handling.
    You are right that it would be bad to name any non-ACPI bits dmar
    ...

    Would you want to move the non-ACPI bits to within
    drivers/pci/intel-iommu.c perhaps? Or do you consider those bits too
    platform specific? (intel-iommu.c is nicely generic right now.)

    > It's a bit premature to do that now, though -- especially given
    > the unfortunate likelihood that a sensible discovery method will
    > never happen.

    PCI IDs are actually a pretty good and stable hardware discovery
    method.

    And such movement away from BIOS enumeration and towards PCI IDs and
    direct hardware access is happening (albeit slowly and somewhat
    sporadically), we saw it recently for some PCI mmconfig bits - i.e.
    it's not just for downstream PCI hardware but for more
    infrastructure bits too.

    But i'd agree with you that Intel-IOMMU bits will take quite some
    time to be discovered via some other method ... and even if they
    will be, it will be EFI - which is a few layers of pointless
    abstractions worse than ACPI so definitely not a step forward.

    Ingo


    \
     
     \ /
      Last update: 2009-04-07 08:45    [W:2.822 / U:0.088 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site