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
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_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
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_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
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_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel