From mboxrd@z Thu Jan 1 00:00:00 1970 From: Olaf Hering Subject: Re: [PATCH 0 of 2] Mem event ring management overhaul Date: Tue, 6 Dec 2011 18:26:05 +0100 Message-ID: <20111206172605.GA18176@aepfle.de> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Content-Disposition: inline In-Reply-To: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Andres Lagar-Cavilla Cc: andres@gridcentric.ca, xen-devel@lists.xensource.com, tim@xen.org, keir.xen@gmail.com, adin@gridcentric.ca List-Id: xen-devel@lists.xenproject.org On Mon, Dec 05, Andres Lagar-Cavilla wrote: > Ensure no guest events are ever lost in the mem event ring. > > This is one of two outstanding proposals to solve this issue. One > key difference between them being that ours does not necessitate wait > queues. > > Instead, we rely on foreign domain retry (already in place), preempting > hypercalls that may cause unbounded guest events (such as > decrease_reservation), and ensuring there is always space left in the > ring for each guest vcpu to place at least one event. Thats not enough. Cases like hvm_copy and the emulator do currently no retry, instead they get an invalid mfn and crash the guest. Its possible to code around that in some places, like shown in the URL below, but wouldnt it make sense to just stop execution until the expected condition is met? Its not clear to me how to properly handle a full ring in get_gfn_type_access() with your proposal. Olaf http://old-list-archives.xen.org/archives/html/xen-devel/2011-01/msg01121.html