Actually, making bus_to_virt() use mfn_to_local_pfn() directly seems better,
as that allows easier cutting off any !pfn_valid() results as well as, in the
HIGHMEM case, even cutting off at max_low_pfn (a hypothetical
machine_to_local_phys() would need its result converted back to a pfn,
so it would seem wasteful to add it unless there were other anticipated users).
Jan
>>> Keir Fraser <Keir.Fraser@xxxxxxxxxxxx> 05.07.07 12:13 >>>
This change would be fine, I'm pretty sure, although it might slow down pte
accesses since machine_to_phys() is used in pte_val() and friends. Perhaps a
machine_to_local_phys() would be the best way to go?
-- Keir
On 5/7/07 11:04, "Jan Beulich" <jbeulich@xxxxxxxxxx> wrote:
> Isn't it inappropriate for bus_to_virt() to use, through machine_to_phys(),
> mfn_to_pfn() rather than mfn_to_local_pfn()? If a foreign domain's address
> gets uses here, the virtual address returned might be anything. I'm
> specifically asking because I finally want to make an attempt to (a) merge
> our swiotlb.c up with native's lib/swiotlb.c and then (b) move ours to
> lib/swiotlb-xen.c. Native, however, uses a virtual address range check, and
> hence the bus_to_virt() return value must reliable. If changing the macro
> globally isn't appropriate (I can't see what valid uses there might be for
> this
> macro with non-local addresses, hence a change like this would be benign to
> all other users), I'd have to hand-craft a mechanism local to swiotlb.c to
> that
> I can keep the delta to native down.
>
> Thanks, Jan
>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@xxxxxxxxxxxxxxxxxxx
> http://lists.xensource.com/xen-devel
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
Home