Hi,
At 11:24 +0800 on 02 Dec (1228217091), Jiang, Yunhong wrote:
> We are considering utilize the live migration mechanism to
> achieve the two steps. The user space tools will firstly mark page
> offline_pending through hypercall, this hyercall will also return the
> owners of the pages. secondly, if all pages can be offlined, user
> space tools should live migrate the domains owning those
> pages.
What do you mean by "live migrate" here? Presuambly you can do
something a lot more lightweight, just pausing the guest for a
checkpoint, changing one or two p2m entries, and letting it resume.
> Following hypercall will be added:
> int xen_page_offline_pending(int start_pfn, int end_pfn, void *result,
> void *owners)
> IN: start_pfn/end_pfn:
> the range of pages to be offlined.
> OUT: result:
> A buffer contain the page status for each page, it can be:
> offlined: the page is offlined already (e.g. the page
> is already freed when the hypercall happen)
> offline_pending: the page will be offline when freed
> offline_fail: The page can't be offline, may because it
> is used by xen/dom0. Notice is, if any page is marked offline_fail, this
> hypercall will not change any page's status (i.e. no page will be marked
> offline_pending or offlined) to make sure atomic operation.
> other status: Other status to be defined in future.
Should this buffer be IN/OUT? The caller has to allocate it anyway and
it would give a more general interface than the start/end arguments.
> OUT: owners:
> A buffer contains the domains owning of the pages. Because of
> security consideration, it will not state which domain owning which page.
Why not? Presumably the caller needs to have privilege over all those
domains anyway in order to mark their frames pending-offline.
> Need notice is, issue exists for the live migrate mechanism:
> a) the domain ID will be changed after live migrate
> b) live migration will fail for a domain with device assigned, so user
> space tools have to hot remove the device, or fail the page offline
> requirement
Both of those issues go away if you don't use a full migrate.
Cheers,
Tim.
--
Tim Deegan <Tim.Deegan@xxxxxxxxxx>
Principal Software Engineer, Citrix Systems (R&D) Ltd.
[Company #02300071, SL9 0DZ, UK.]
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
Home