This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
Home Products Support Community News


Re: [Xen-devel] Re: [Xen-staging] [xen-unstable] linux: User-space grant

To: Alex Williamson <alex.williamson@xxxxxx>
Subject: Re: [Xen-devel] Re: [Xen-staging] [xen-unstable] linux: User-space grant table device.
From: Keir Fraser <Keir.Fraser@xxxxxxxxxxxx>
Date: Sat, 31 Mar 2007 18:28:18 +0100
Cc: xen-devel@xxxxxxxxxxxxxxxxxxx
Delivery-date: Sat, 31 Mar 2007 18:28:35 +0100
Envelope-to: Keir.Fraser@xxxxxxxxxxxx
In-reply-to: <1175358869.13963.60.camel@bling>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: AcdzufiUNyi48N+tEduWXQAWy6hiGQ==
Thread-topic: [Xen-devel] Re: [Xen-staging] [xen-unstable] linux: User-space grant table device.
User-agent: Microsoft-Entourage/

On 31/3/07 17:34, "Alex Williamson" <alex.williamson@xxxxxx> wrote:

>> Everyone should build it and the x86-specific portions (if there really are
>> any -- it all looks pretty generic to me even if no other architectures
>> currently use the functions defined in there) should be ifdef'ed or perhaps
>> relocated to a new file.
>    True, util.c ought to be a good place to dump stuff like this.
> Unfortunately we define our own alloc/free_vm_area(), so the existing
> functions in there are the problems.  Maybe those should be moved to
> arch/i386/mach-xen/util.c, or ifdef out as below.  Thanks,

Oh I see. Actually I think the difference is not strictly
architecture-related, but due to the fact that ia64 uses auto-translate, so
you need actual pseudophysical addresses relating to the virtual address
that is returned. The right answer here is to have a combined function that
tests for auto_translated_physmap. Possibly the interface function should
even be modified to do allocate-area-and-map, rather than leaving the
mapping to a separate function. Anyhow, for now I'll make the 'generic'
versions __attribute__((weak)).

 -- Keir

Xen-devel mailing list