Messages in this thread | | | Date | Thu, 09 Apr 2009 12:19:19 -0700 | From | Jeremy Fitzhardinge <> | Subject | Re: [PATCH 4/7] swiotlb: Allow arch override of address_needs_mapping |
| |
FUJITA Tomonori wrote: >> Well, Becky's patches also added the hwdev argument to them, so >> presumably the powerpc implementation needs that (different >> devices/buses have differing views of physical memory, I guess). >> > > Until I see the ppc specific swiotlb patchset, I'm not sure but I > think that we can remove phys_to_bus in swiotlb. >
Kumar's comment was: "For our SoC chips we don't need any mapping between phys & bus. However something like PCI does have a mapping (a simple offset)."
Kumar, could a single system have different phys<->bus mappings on a single system, or could it differ from device to device (or bus to bus)?
> Even if we need phys_to_bus, we can remove the rest of __weak tricks > for only dom0. And we can make phys_to_bus arch-specific. Then we > don't need any __weak tricks in swiotlb (and x86's swiotlb). dom0 > support adds many hacks to swiotlb. >
Well, we'd still need a way to do hook the swiotlb_alloc(_boot) allocation. At the moment its effectively arch-specific because x86 only uses swiotlb_alloc_boot(), and ia64 only uses swiotlb_alloc(). One option would be to simply make that function arch-defined, which would remove the need for any kind of override mechanism in lib/swiotlb; that would match the handling of phys_to_bus. And its more appealing if we manage to drop swiotlb_alloc_boot, so there's only a single function for the arches to worry about.
> Yeah, ISA DMA comment is misleading. swiotlb can't handle it. And it > doesn't need to handle it because the block layer can thanks to > the bouncing (the network layer does the similar, I think). > > As you said, we could remove the latter though I'm not sure. >
It would take a bit of rearranging the x86 swiotlb/iommu init sequence, but I don't think it would be too complex. I'll look into it.
J
| |