|
|
|
|
|
|
|
|
|
|
xen-devel
[Xen-devel] Re: [PATCH 00 of 14] swiotlb/x86: lay groundwork for xen dom
To: |
Becky Bruce <beckyb@xxxxxxxxxxxxxxxxxxx> |
Subject: |
[Xen-devel] Re: [PATCH 00 of 14] swiotlb/x86: lay groundwork for xen dom0 use of swiotlb |
From: |
Ingo Molnar <mingo@xxxxxxx> |
Date: |
Thu, 18 Dec 2008 22:02:31 +0100 |
Cc: |
Jeremy Fitzhardinge <jeremy@xxxxxxxx>, xen-devel@xxxxxxxxxxxxxxxxxxx, ian.campbell@xxxxxxxxxx, joerg.roedel@xxxxxxx, x86@xxxxxxxxxx, Linux Kernel Mailing List <linux-kernel@xxxxxxxxxxxxxxx>, FUJITA Tomonori <fujita.tomonori@xxxxxxxxxxxxx>, Benjamin Herrenschmidt <benh@xxxxxxxxxxxxxxxxxxx> |
Delivery-date: |
Thu, 18 Dec 2008 13:03:36 -0800 |
Envelope-to: |
www-data@xxxxxxxxxxxxxxxxxxx |
In-reply-to: |
<E5300CC0-1D08-46F7-91F6-DEC36202F1DE@xxxxxxxxxxxxxxxxxxx> |
List-help: |
<mailto:xen-devel-request@lists.xensource.com?subject=help> |
List-id: |
Xen developer discussion <xen-devel.lists.xensource.com> |
List-post: |
<mailto:xen-devel@lists.xensource.com> |
List-subscribe: |
<http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> |
List-unsubscribe: |
<http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> |
References: |
<20081216203513.GA14787@xxxxxxx> <20081217142637V.fujita.tomonori@xxxxxxxxxxxxx> <4949296F.7000701@xxxxxxxx> <20081218015705Z.fujita.tomonori@xxxxxxxxxxxxx> <E5300CC0-1D08-46F7-91F6-DEC36202F1DE@xxxxxxxxxxxxxxxxxxx> |
Sender: |
xen-devel-bounces@xxxxxxxxxxxxxxxxxxx |
User-agent: |
Mutt/1.5.18 (2008-05-17) |
* Becky Bruce <beckyb@xxxxxxxxxxxxxxxxxxx> wrote:
>> Can you be more specific? What architecture is plan to use highmem
>> support in swiotlb?
>
> 32-bit powerpc needs this support - I was actually about to push a
> similar set of patches. We have several processors that support 36 bits
> of physical address space and do not have any iommu capability. The
> rest of the kernel support for those processors is now in place, so
> swiotlb is the last piece of the puzzle for that to be fully functional.
> I need to take a closer look at this series to see exactly what it's
> doing and how it differs from what I've been testing.
>
> So there is another immediate use case, and I'd really hate to see this
> code duplicated. It should be entirely possible to remove the
> assumption that we can save off the VA of the original buffer, which is
> the thing that precludes HIGHMEM support, and still have nice readable,
> maintainable code.
you can have a look at Jeremy's current lineup of patches in
tip/core/iotlb:
http://people.redhat.com/mingo/tip.git/README
(also integrated into tip/master)
What would be needed to make it suit your usecase too?
Ingo
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
|
|
|
|