linux-kernel - Re: [GIT *] intel-iommu updates for 2.6.30 (second batch)

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20090407063917.GA12410@elte.hu>
Date:	Tue, 7 Apr 2009 08:39:17 +0200
From:	Ingo Molnar <mingo@...e.hu>
To:	David Woodhouse <dwmw2@...radead.org>
Cc:	torvalds@...ux-foundation.org, iommu@...ts.linux-foundation.org,
	linux-kernel@...r.kernel.org
Subject: Re: [GIT *] intel-iommu updates for 2.6.30 (second batch)

* David Woodhouse <dwmw2@...radead.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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/