Tim Deegan <mailto:Tim.Deegan@xxxxxxxxxx> wrote:
> Hi,
>
> At 10:02 +0800 on 04 Dec (1228384976), Jiang, Yunhong wrote:
>>> True, but live-migration doesn't help that because right now given an
>>> MFN that's in use as a shadow page or any HVM state page you can't
>>> easily find out which domain is responsible for it.
>>
>> Ahh, yes, didn't realize this. So do you think it is ok to add such
>> information?
>
> Maybe for shadow pagetables something could be done, though
> I'm not sure
> there's room in the frametable. I think the other frames are
> sufficiently few that if you're already excluding xenheap and dom0 they
> won't make much difference.
Yes, at least in first stage we will not do that. After all, we just need cover
the majority of the frames.
We many need extra 2 bit in frametable to mark page offline status, not sure if
that's ok.
>
>>> Also, remember that full live-migration needs enough spare RAM to hold
>>> an extra copy of the guest, so it couldn't work on guests larger than
>>> half the physical RAM, for example.
>>
>> Yes, that is one argument we thought that before.
>>
>>>
>>>> d) For PV guest, can this be done without co-operation from guest?
>>>
>>> Yes it can. As long as you don't use the "fast path" resume to restart
>>> the guest, it will re-read its p2m just like it would after a full
>>> save/restore.
>>
>> What do you mean of the "fast path"?
>
> Have a look at the code for xc_domain_resume in libxc/xc_resume.c. The
> slow-and-safe version makes the domain state look like it would after a
> save/restore, so that older kernels can be resumed after they've paused
> and had their state saved. The fast version just changes the return
> code that the guest will see from its shutdown hypercall.
>
> My suggestion is that you cause the guest to stop like it would for a
> save to disk, shuffle its p2m around, and call the slow-path resume
> function so that it will pick up the new p2m properly.
I will dig-into the code Thanks for your suggestion.
>
>> Do you mean the "something very lightweight based on small parts of
>> the save/restore code" is done in management tools, not in HV, am I
>> right?
>
> Yes. For the common case this lets you get what you want without the
> hypervisor being involved.
So maybe the policy can be: if HV can offline page easily (like page owned by
hvm domain without device assigned, or free pages), HV will do that, otherwise,
we will leave it to user space tools.
We will firstly implement the code in HV side.
>
> 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