[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

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 

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

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



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.