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/
Home Products Support Community News


[Xen-devel] RE: [PATCH] Support swap a page from user space tools -- Was

To: Keir Fraser <keir.fraser@xxxxxxxxxxxxx>, Tim Deegan <Tim.Deegan@xxxxxxxxxxxxx>
Subject: [Xen-devel] RE: [PATCH] Support swap a page from user space tools -- Was RE: [RFC][PATCH] Basic support for page offline
From: "Jiang, Yunhong" <yunhong.jiang@xxxxxxxxx>
Date: Thu, 19 Mar 2009 22:26:26 +0800
Accept-language: en-US
Acceptlanguage: en-US
Cc: "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>
Delivery-date: Thu, 19 Mar 2009 07:27:14 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <C5E7F7AF.4891%keir.fraser@xxxxxxxxxxxxx>
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: <E2263E4A5B2284449EEBD0AAB751098401C7EC06F6@xxxxxxxxxxxxxxxxxxxxxxxxxxxx> <C5E7F7AF.4891%keir.fraser@xxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: AcmodaxGpRh5muaRTCCma6vBJRy3NQAAdKadAAA4ExAAAMDH0QAFXe2AAAE9geEAAiC0AA==
Thread-topic: [PATCH] Support swap a page from user space tools -- Was RE: [RFC][PATCH] Basic support for page offline
Keir Fraser <mailto:keir.fraser@xxxxxxxxxxxxx> wrote:
> On 19/03/2009 13:01, "Jiang, Yunhong" <yunhong.jiang@xxxxxxxxx> wrote:
>> Instead of add a new mmu_*op, I try to change the MMU_NORMAL_PT_UPDATE to
>> support update foreign page table. There will be some restirction for it,
>> including the pagetable and the new mfn pointed should be owned by same
>> domain, and the domain should be suspeneded already. The
>> update_foregin_pt.patch is for this. I'm not sure if this method is
>> feasible. 
> I'll need to look in more detail, but yes it does appear this
> approach can
> work. This is probably the easiest way to go in that case.
>> The exchange_page.patch is to replace a mfn with a new one. Although there
>> is already a memory_exchange hypercall, but that hypercall will not accept
>> new page, add that support will break current ABI. Also it does not support
>> foreign domain. This function add those support
> Well, why is the existing hypercall not okay by itself? Why
> can you not take
> an arbitrary new mfn and you feel you have to specify it from the tools
> instead? 

It is ok for us to use an arbitrary new mfn, and then do the update_entry. But 
what happen if this process failed and we want to turn back to the old page? We 
still need this mechanism at that situation.

Yunhong Jiang

> -- Keir
Xen-devel mailing list

<Prev in Thread] Current Thread [Next in Thread>