WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

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

To: Tim Deegan <Tim.Deegan@xxxxxxxxxx>
Subject: RE: [Xen-devel] [Question] How to support page offline in Xen environment
From: "Jiang, Yunhong" <yunhong.jiang@xxxxxxxxx>
Date: Thu, 4 Dec 2008 10:02:56 +0800
Accept-language: en-US
Acceptlanguage: en-US
Cc: "Wang, Shane" <shane.wang@xxxxxxxxx>, "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>
Delivery-date: Wed, 03 Dec 2008 18:03:57 -0800
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <20081203104506.GN25331@xxxxxxxxxxxxxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <E2263E4A5B2284449EEBD0AAB751098401C309F6C3@xxxxxxxxxxxxxxxxxxxxxxxxxxxx> <20081203100910.GM25331@xxxxxxxxxxxxxxxxxxxxx> <E2263E4A5B2284449EEBD0AAB751098401C30DCF7E@xxxxxxxxxxxxxxxxxxxxxxxxxxxx> <20081203104506.GN25331@xxxxxxxxxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: AclVNEOtcthOmhk/QuaVdJjJPi1PVQAfs9ug
Thread-topic: [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 
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