bus_to_virt()

bus_to_virt()

[Jan Beulich]

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

Re: bus_to_virt()

[Keir Fraser]

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@novell.com> 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@lists.xensource.com
> http://lists.xensource.com/xen-devel

Re: bus_to_virt()

[Jan Beulich]

Yes, machine_to_local_phys() was my thinking here, too. Jan

>>> Keir Fraser <Keir.Fraser@cl.cam.ac.uk> 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@novell.com> 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@lists.xensource.com 
> http://lists.xensource.com/xen-devel 

Re: bus_to_virt()

[Jan Beulich]

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@cl.cam.ac.uk> 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@novell.com> 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@lists.xensource.com 
> http://lists.xensource.com/xen-devel