From mboxrd@z Thu Jan  1 00:00:00 1970
From: "Jan Beulich" <jbeulich@novell.com>
Subject: Re: bus_to_virt()
Date: Thu, 05 Jul 2007 11:39:12 +0100
Message-ID: <468CE670.76E4.0078.0@novell.com>
References: <468CDE37.76E4.0078.0@novell.com>
	<C2B282DB.A56E%Keir.Fraser@cl.cam.ac.uk>
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Return-path: <xen-devel-bounces@lists.xensource.com>
In-Reply-To: <C2B282DB.A56E%Keir.Fraser@cl.cam.ac.uk>
Content-Disposition: inline
List-Unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com
To: Keir Fraser <Keir.Fraser@cl.cam.ac.uk>, xen-devel@lists.xensource.com
List-Id: xen-devel@lists.xenproject.org

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