lkml.org 
[lkml]   [2008]   [Dec]   [18]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH 00 of 14] swiotlb/x86: lay groundwork for xen dom0 use of swiotlb

* Jeremy Fitzhardinge <jeremy@goop.org> wrote:

> FUJITA Tomonori wrote:
>> On Wed, 17 Dec 2008 08:31:43 -0800
>> Jeremy Fitzhardinge <jeremy@goop.org> 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


\
 
 \ /
  Last update: 2008-12-18 14:27    [from the cache]
©2003-2011 Jasper Spaans