On 18/12/06 7:44 am, "Jan Beulich" <jbeulich@xxxxxxxxxx> wrote:
>> Same here. We didn't implement this. It doesn't seem to make that much
>> sense. Sync'ing with lib/swiotb.c and throwing away our special one would be
>> very nice. :-)
>
> Trying to do that I find one extra issue: in_swiotlb_aperture() does its check
> based on pfn, while lib/swiotlb.c uses the virtual address in the respective
> checks instead. Is there some subtlety behind that (that then should be
> commented upon), or is this just due to this originally having been an
> mfn-based check?
Yes, it's because we used to do an mfn range check which was okay when the
swiotlb aperture was filled with contiguous machine memory. Since it is
composed of discontiguous slabs now, we changed to a pfn check but that
could equally well be a virtual-address check.
Do we merge okay with lib/swiotlb.c then? One concern I had was with our
preferred setup semantics -- we really want the user to be able to forcibly
enable the swiotlb via a boot parameter *but* not have to suffer using it
for every DMA operation. Last I looked the generic swiotlb didn't have that
option. That and our very Xen-specific checks for whether to auto-enable the
swiotlb led me to think that the very start-of-day setup of swiotlb would
need to be overridable by architecture.
 -- Keir
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel