Hi,
On Thu, 2006-10-05 at 16:47 +0100, Keir Fraser wrote:
> > I've been looking at the exact same question, but don't know the
> > answer. If you come up with a patch before I do, I'd be thrilled to
> > test it.
>
> This is easily fixable. Anywhere we use the virtual address to compute an
> offset into a state structure, we can instead store the appropriate 'slot
> index' in a spare field in the appropriate 'struct page'.
As far as I can tell, nothing uses the VA in any way --- it can't,
because the start of the order-10 kmalloc area is not actually used
anywhere after the initial mmap setup. After making the variable
mmap_vstart local to the __init function, everything still compiles, so
I don't think there's anything lurking in header files that implicitly
relies on it.
There is a
ret = HYPERVISOR_memory_op(XENMEM_decrease_reservation,
&reservation);
call on the entire range, though, if (xen_feature
(XENFEAT_auto_translated_physmap)) is true. Those reservations are one-
off requests, aren't they? I don't think we're adding overhead by doing
this for 1024 separate pages rather than a single order-10 chunk, but
I'd appreciate a second opinion there.
> That really only leaves the question of how much of this can be put in a
> helper function (probably in balloon driver again) for use of all our
> drivers.
Right --- a helper which returns a vm-detached page vector rather than a
vaddr is exactly what I had in mind.
--Stephen
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
Home