WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

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

<Prev in Thread] Current Thread [Next in Thread>