[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [Xen-devel] Re: [PATCH 00 of 14] swiotlb/x86: lay groundwork for xen dom0 use of swiotlb
* 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
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |