On 04/11/2011 10:38, "Jean Guyader" <jean.guyader@eu.citrix.com> wrote:
>
> XENMAPSPACE_gmfn_range is like XENMAPSPACE_gmfn but with a size which
> is the number of pages on which xen will iterate.
You can't really extend the size of an existing ABI structure, and always
copy that extended size. Older guests won't know to guarantee that the
extended space is accessible. I suggest you make your new field a uint16_t,
placed directly after the domid field. Then you are making use of existing
pad space. 64k pages = 256MB at a time should be plenty of amortisation.
And, even with the reduced field width, I could imagine 64k remappings
taking a good while. The remapping loop should regularly (even every
iteration) check hypercall_preempt_check(), then
hypercall_create_continuation() and exit if the hypercall is being requested
to voluntarily yield.
-- Keir
> Signed-off-by: Jean Guyader <jean.guyader@eu.citrix.com>
> ---
> xen/arch/x86/mm.c | 15 ++++++++++++++-
> xen/include/public/memory.h | 4 ++++
> 2 files changed, 18 insertions(+), 1 deletions(-)
>
> _______________________________________________
> 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
