From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Andres Lagar-Cavilla" Subject: Re: [PATCH] x86/mm: Improve ring management for memory events. Do not lose guest events Date: Fri, 13 Jan 2012 12:05:23 -0800 Message-ID: References: <20120113095022.GA18130@aepfle.de> <873a666b95bbe7e50992fb1059bc2220.squirrel@webmail.lagarcavilla.org> <20120113195706.GA26566@aepfle.de> Reply-To: andres@lagarcavilla.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <20120113195706.GA26566@aepfle.de> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Olaf Hering Cc: andres@gridcentric.ca, xen-devel@lists.xensource.com, tim@xen.org, adin@gridcentric.ca List-Id: xen-devel@lists.xenproject.org > On Fri, Jan 13, Andres Lagar-Cavilla wrote: > >> > p2m_mem_paging_drop_page() should remain void because the caller has >> > already done its work, making it not restartable. Also it is only >> called >> > when a gfn is in paging state, which I'm sure can not happen without a >> > ring. >> >> Well, the rationale is that returning an error code can only help, >> should >> new error conditions arise. Keep in mind that the pager and the ring can >> disappear at any time, so ENOSYS can still happen. > > The ring should rather not disappear at all until ->paged_pages drops to > zero. Unless the goal is a restartable pager, > XEN_DOMCTL_MEM_EVENT_OP_PAGING_DISABLE should return -EBUSY when > ->pages_pages is not zero. Then the checks in drop_page and populate can > be relaxed. Well, there are two separate things here. Should drop return an error code? No harm in that. Then there is your point about the ring not going away if ->paged_pages is nonzero. Which I like, but is currently not implemented, afaict. Separate patch I guess. > >> I'll refresh and add your signed-off-by to cover the portions of the >> work >> that originate from your end, is that ok? > > I havent finish the review yet, have to check how it may work with wait > queues in gfn_to_mfn*. Another case of "the two separate things" :) We definitely look forward to wait queue support for gfn_to_mfn*. But that's a separate consumer of the wait queue feature. Are you worried that this patch might break your gfn_to_mfn* strategy? We did base it on your work. Thanks, Andres > > Olaf >