Prev: max3107: Fix gpiolib support
Next: KVM: SVM: Sync efer back into nested vmcb
From: Konrad Rzeszutek Wilk on 2 Aug 2010 12:50
On Tue, Aug 03, 2010 at 01:01:08AM +0900, FUJITA Tomonori wrote:
> On Mon, 02 Aug 2010 08:47:53 -0700
> "H. Peter Anvin" <hpa(a)zytor.com> wrote:
>
> > On 08/02/2010 08:43 AM, FUJITA Tomonori wrote:
> > >
> > > That's the difficult part because IOMMUs are not
> > > interdependent. Hardware IOMMUs are related with swiotlb. GART and
> > > AMD-IOMMU are too.
> > >
> > > We could invent sorta IOMMU register interface and driver-ize IOMMUs
> > > but they can't be interdependent completely.
> >
> > Of course. However, we need there to be as much structure to it as
> > there can be.
>
> Ok, let's see if Konrad can invent something clean.

<chuckles> Thank you for your vote of confidence.
>
> But his attempt to create "swiotlb iommu function array" and "hardware
> iommu function array" looks like to makes the code more unreadable.

Let me go to my favorite coffee shop and think this one through.
Can I get concession for putting the original patch in (the simple, dumb one),
and then:
- start working on the IOMMU register interface without having to try
to get it done for 2.6.36, and
- do the driverization as a seperate cleanup.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: H. Peter Anvin on 2 Aug 2010 13:00
On 08/02/2010 09:42 AM, Konrad Rzeszutek Wilk wrote:
>
> Let me go to my favorite coffee shop and think this one through.
> Can I get concession for putting the original patch in (the simple, dumb one),
> and then:
> - start working on the IOMMU register interface without having to try
> to get it done for 2.6.36, and
> - do the driverization as a seperate cleanup.
>

That makes sense.

-hpa

--
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel. I don't speak on their behalf.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: FUJITA Tomonori on 3 Aug 2010 01:40
On Mon, 2 Aug 2010 12:42:34 -0400
Konrad Rzeszutek Wilk <konrad.wilk(a)oracle.com> wrote:

> > But his attempt to create "swiotlb iommu function array" and "hardware
> > iommu function array" looks like to makes the code more unreadable.
>
> Let me go to my favorite coffee shop and think this one through.
> Can I get concession for putting the original patch in (the simple, dumb one),
> and then:
> - start working on the IOMMU register interface without having to try
> to get it done for 2.6.36, and
> - do the driverization as a seperate cleanup.

We could simplify swiotlb initialization after 2.6.36. If we merge my
patches to expand swiotlb memory dynamically, we could initialize
swiotlb before any hw IOMMUs (see the commit
186a25026c44d1bfa97671110ff14dcd0c99678e).

If you can make Xen swiotlb initialized like HW iommu, the IOMMU
initialization could be cleaner.

As I wrote, I also want to simplify swiotlb's init memory
allocation. I'll see what I can do on the whole issue.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
First  |  Prev  | 
Pages: 1 2 3 4
Prev: max3107: Fix gpiolib support
Next: KVM: SVM: Sync efer back into nested vmcb