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: Jeremy Fitzhardinge <jeremy@xxxxxxxx>
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 14:23:13 +0100
Cc: xen-devel@xxxxxxxxxxxxxxxxxxx, ian.campbell@xxxxxxxxxx, joerg.roedel@xxxxxxx, x86@xxxxxxxxxx, linux-kernel@xxxxxxxxxxxxxxx, FUJITA Tomonori <fujita.tomonori@xxxxxxxxxxxxx>
Delivery-date: Thu, 18 Dec 2008 05:24:02 -0800
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <49494BE4.1070408@xxxxxxxx>
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> <49494BE4.1070408@xxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Mutt/1.5.18 (2008-05-17)
* Jeremy Fitzhardinge <jeremy@xxxxxxxx> wrote:

> FUJITA Tomonori wrote:
>> On Wed, 17 Dec 2008 08:31:43 -0800
>> Jeremy Fitzhardinge <jeremy@xxxxxxxx> wrote:
>>
>>   
>>>> I think that the whole patchset is against the swiotlb design. swiotlb
>>>> is designed to be used as a library. Each architecture implements the
>>>> own swiotlb by using swiotlb library
>>>> (e.g. arch/x86/kernel/pci-swiotlb_64.c).
>>>>         
>>> The whole patchset?  The bulk of the changes to lib/swiotlb.c are  
>>> relatively minor to remove the unwarranted assumptions it is making 
>>> in the face of a new user.  They will have no effect on other 
>>> existing users, including non-Xen x86 builds.
>>>
>>> If you have specific objections we can discuss those, but I don't 
>>> think there's anything fundamentally wrong with making lib/swiotlb.c 
>>> a bit more generically useful.
>>>     
>>
>> Sorry, but the highmem support is not generically useful.
>>   
>
> That's a circular argument.  lib/swiotlb currently used by 1 1/2 of the 
> 23 architectures, neither of which happens to use highmem.  If you 
> consider swiotlb to be a general purpose mechanism, then presumably the 
> other 21 1/2 architectures are at least potential users (and 6 1/2 of 
> those have highmem configurations).  If you base your judgement of 
> what's a "generically useful" change based on what the current users 
> need, then you'll naturally exclude the requirements of all the other 
> (potential) users.
>
> And the matter arises now because we're trying to unify the use of 
> swiotlb in x86, bringing the number of users up to 2.
>
>> I'm especially against the highmem support. As you said, the rest looks 
>> fine but if you go with pci-swiotlb_32.c, I think that you don't need 
>> the most of them.
>>   
>
> I really don't want to have to duplicate a lot of code just to 
> incorporate a few small changes.  In fact the original Xen patch set 
> included its own swiotlb implementation, and that was rejected on the 
> grounds that we should use the common swiotlb.c.

duplicating that would not be a very good design - and 32-bit highmem is a 
reality we have to live with for some time to come. The impact:

   10 files changed, 251 insertions(+), 81 deletions(-)

looks rather to the point and seems relatively compressed. In fact 32-bit 
Xen could end up being the largest user (and tester) of swiotlb facilities 
in general, as modern 64-bit platforms tend to have hw IOMMUs. Having more 
code sharing and more testers is a plus.

        Ingo

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

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