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: Jeremy Fitzhardinge <jeremy@xxxxxxxx>
Date: Thu, 18 Dec 2008 23:02:00 -0800
Cc: 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>, Ingo Molnar <mingo@xxxxxxx>
Delivery-date: Thu, 18 Dec 2008 23:02:33 -0800
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <3853A0F2-F817-4263-9EF9-9A0655BF95CD@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> <20081218210231.GB24271@xxxxxxx> <3853A0F2-F817-4263-9EF9-9A0655BF95CD@xxxxxxxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Thunderbird 2.0.0.18 (X11/20081119)
Becky Bruce wrote:
I've taken a quick look at the series posted to the list, and they're actually very similar to what I've done. I think there are really only 3 fairly minor issues that need to be resolved to make this work on ppc:

1) We need to add swiotlb_map/unmap_page calls, as those are part the ppc dma_mapping_ops (in fact, we don't have map/unmap_single in the dma_mapping_ops struct on ppc anymore - those just call map/unmap_page). This is really just a matter of moving some code around and making some minor changes, as swiotlb_map/unmap_single can call swiotlb_map/unmap_page once the args have been converted. There's a patch in my series that should make this pretty obvious.

2) To convert any address to/from a bus address, we also need the hwdev pointer passed as an argument since ppc supports a per-device offset accessed via the device ptr that is used to calculate the bus address. I'd also given my conversion functions more generic names, as it seemed highly likely that these would eventually be useful outside of the swiotlb code.

3) powerpc uses enum dma_data_direction for the direction argument to its dma_ops, which is, from reading the kernel docs, the correct argument type for the DMA API functions. However, the iotlb/x86/ia64 code is currently using an int. This causes a build warning when we initialize the dma_ops struct using the swiotlb funcs. Is there a reason for the use of "int" in x86/ia64? The Right Thing(TM) here seems to be to convert those over to using the enum, and I have a big patch that starts doing that, but I've probably missed some places. I could instead do some hackery on the ppc side, and leave the other platforms alone, but I'd prefer to do it cleanly. Thoughts?

Unfortunately, this is horrible timing for me, as starting tomorrow, I'm going to be offline for a week and a half or so in podunk Louisiana with essentially no net access. I can integrate my code into your tree and test on PPC as soon as I return to the real world.

Yeah, I think that's OK. The important thing at this point is to determine whether the two patch sets are aligned or conflicting. It sounds like they're largely aligned, and so generating a delta from my patches to match your needs will be relatively straightforward.

I'm trying to line all this Xen stuff up for this merge window, so I'd prefer to revisit it in the next dev cycle. Did you want to get something into this merge window?

   J

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel

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