linux-kernel - Re: PCIE

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 for Android: free password hash cracker in your pocket

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

Date:	Sun, 27 May 2007 19:54:05 -0700 (PDT)
From:	David Miller <davem@...emloft.net>
To:	rdreier@...co.com
Cc:	abraham.manu@...il.com, greg@...ah.com,
	linux-pci@...ey.karlin.mff.cuni.cz, linux-kernel@...r.kernel.org
Subject: Re: PCIE

From: Roland Dreier <rdreier@...co.com>
Date: Sun, 27 May 2007 18:03:29 -0700

> I have a hard time imagining a PCI host bus controller that converts
> MSI interrupts back to wire interrupts that go to pins on the CPU.
> For one thing it would be hard to maintain the guarantee that
> MSI interrupts can't pass DMAs.  And it would be an absolutely silly
> architecture too.

We are definitely going to see systems like this, and the DMA issue
will be taken care of by the PCI host controller, it will either pull
out all queued up DMA writes by the device in question itself
(somehow) or require the driver for the PCI host controller do a dummy
read out to the device before servicing an interrupt handler to
guanentee this semantic.

We already have pre-PCI-E controllers on sparc64 where I have to do a
dummy config space read to pull out all the pending DMA requests
before servicing an interrupt, so this kind of scheme would be nothing
new.

People are going to use PCI-E on very inexpensive and primitive cpu
platforms.

The thing to do for such platforms is the use virtual IRQ numbers and
interrogate the PCI-E controller for the MSI number when the CPU level
interrupt arrives and translate that into the appropriate virtual IRQ.
-
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/