RE: [Xen-devel] [Question] How to support page offline in Xen environment

["Jiang, Yunhong" <yunhong.jiang@xxxxxxxxx>]

Tim Deegan <mailto:Tim.Deegan@xxxxxxxxxx> wrote:
> At 18:30 +0800 on 03 Dec (1228329001), Jiang, Yunhong wrote:
>> a) A page is foreign mapped by another guest (e.g. dom0),
> change p2m entries is not enough.
> 
> True.
> 
>> b) A page is assigned to a domain with device assigned, we
> can't simply change the p2m entry because of DMA operation may
> on-going. (this in fact can't resolve cleanly through live
> migration, although the tools do hot remove in advance).
> 
> That seems to be orthogonal to the question of how the page is got rid
> of; you can do a hot remove and hot add whether you do a full live-migrate
> or not. 
> 
>> c) If a page is used like shadow page table or, virutal
> local apic's page, currently we can't simply exchange these pages.
> 
> 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? 

> 
> 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"?

> 
>> Of course, we can simplify the request, for example, no
> support for page in item a), b) and c) and that will be ok.
>> That's the reason we hope to get suggestion on next step.
> 
> I think it depends on how important it is to be able to offline frames
> quickly and transparently.  If that's not important, then just save the
> owning domain to disk, offline the frames, and restore it.  If it is
> important, I'd be inclined to to something very lightweight based on
> small parts of the save/restore code (which will be much faster than
> live migration), and keep save-to-disk as a backstop for the
> edge cases.
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?

Thanks
Yunhong Jiang

> 
> 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