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


Re: [Xen-devel] Re: how to handle paged hypercall args?

To: Keir Fraser <keir@xxxxxxx>
Subject: Re: [Xen-devel] Re: how to handle paged hypercall args?
From: Olaf Hering <olaf@xxxxxxxxx>
Date: Thu, 11 Nov 2010 21:34:38 +0100
Cc: xen-devel@xxxxxxxxxxxxxxxxxxx
Delivery-date: Thu, 11 Nov 2010 12:35:23 -0800
Dkim-signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1289507686; l=975; s=domk; d=aepfle.de; h=In-Reply-To:Content-Type:MIME-Version:References:Subject:Cc:To:From: Date:X-RZG-CLASS-ID:X-RZG-AUTH; bh=FYzJz8KF8aLyuAvCltc8jPKdTo0=; b=haXYqxisVVbwqXz/1EFXprUJ/48zHm07JAQFEVA+7CzYK0zptM0OIzkpHwNKeGDGHAy 91oMskK+8QsmJJYX6LlMV1sIhlriD2OA9ilVEC9GnQZOV2Cu8ZLVNmz6Rg8qSO5CrADIp 6qCAzfi2xUuN6aC0Uokj4u1phqSQ25p8tck=
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <C901FDDB.999A%keir@xxxxxxx>
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: <20101111143338.GA27721@xxxxxxxxx> <C901FDDB.999A%keir@xxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Mutt/1.5.20 (2009-06-14)
On Thu, Nov 11, Keir Fraser wrote:

> On 11/11/2010 14:33, "Olaf Hering" <olaf@xxxxxxxxx> wrote:
> > So is that an acceptable way to deal with the HVMCOPY_gfn_paged_out
> > return codes from __hvm_copy?
> > Or should I explore some different way, like spinning there and possible
> > let other threads-of-execution make progress while waiting for the gfns
> > to come back?
> You can't just spin because Xen is not preemptible. If it were a single CPU
> system for example, no other thread would ever run again. You have to 'spin'
> via a preemptible loop that returns to guest context and then back into the
> hypercall. Which appears to be what you're doing.

Thanks for the answer.

It occoured to me that this is an issue for hypercalls made by the
guest. There are probably not that many in use. So it shouldnt be that
hard to audit the few drivers what they use and add some error handling.
Up to now, only do_memory_op had an issue.


Xen-devel mailing list