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]
Date:	Fri, 11 Jul 2008 10:20:33 -0700
From:	ebiederm@...ssion.com (Eric W. Biederman)
To:	"Duran, Leo" <leo.duran@....com>
Cc:	"Roedel, Joerg" <Joerg.Roedel@....com>,
	"Richter, Robert" <rrichter@...e.amd.com>,
	"Biemueller, Sebastian" <Sebastian.Biemueller@....com>,
	<linux-kernel@...r.kernel.org>, <iommu@...ts.linux-foundation.org>,
	<mingo@...hat.com>, <tglx@...utronix.de>,
	"Sarathy, Bhavna" <Bhavna.Sarathy@....com>
Subject: Re: [PATCH 00/34] AMD IOMMU driver

"Duran, Leo" <leo.duran@....com> writes:

> On Friday, July 11, 2008 5:22 AM, Eric W. Biederman wrote:
>
>> Small question.  Does this IOMMU also support irq remapping?
>> 
>> Intel is starting to merge support for their iommu that supports irq
>> remapping and I am curious what the implications are going to be to
>> support both of these iommus?
>> 
>> Assuming their is irq remapping support it isn't tied to x2apic
>> support in the cpus is it?
>> 
> Follow-up questions: 
> (1) Outside of a virtualization environment, is there functional value
> for "irq remapping" by an IOMMU? And, if there is, (2) How would this
> functionality get abstracted? (e.g., as dma_ops abstracts 'address
> remapping' by the IOMMU)

Current x86 hardware ioapics have significant issues with irq
migration.  So things like real cpu hotplug are not really
supportable unless there is better hardware or an iommu.

There is a good case for linux to support kernel bypass for some hardware.
>From kvm where linux acts as a hypervisor to crazy people wanting to
device drivers in user space, to the classic HPC mpi stack that
wants to go as fast as possible.

Then there is the Intel case where the are extending their cpu apicids
to 32bit and require going through a hypervisor to encode all of the
necessary bits.  I think we can go to 16bit cpus without doing that
but it is a squeeze.

If we are going to run under under a hypervisor we need at least the
abstraction of going through an iommu (in that case a hypercall) 
so we can run under a hypervisor.

So right now we are just starting to design the abstraction, and I'm
hoping we can get as large a perspective on what it should look like
as we can.  

I expect the api will look something like:
struct irq_map_info x86_map_irq(irq, cpumask);

Where struct irq_map_info would return the architecture defined bits
that we can program into an msi or an ioapic routing entry.

With x86_map_irq looking up an appropriate ops structure and calling
the iommu specific operation.

Eric
--
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ