[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

  • To: Alex Williamson <alex.williamson@xxxxxx>
  • 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
  • List-id: Xen developer discussion <xen-devel.lists.xensource.com>
  • Thread-index: AcdzufiUNyi48N+tEduWXQAWy6hiGQ==
  • Thread-topic: [Xen-devel] Re: [Xen-staging] [xen-unstable] linux: User-space grant table device.

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



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.