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: "Olaf Hering" <olaf@xxxxxxxxx>,"Keir Fraser" <keir@xxxxxxx>
Subject: Re: [Xen-devel] Re: how to handle paged hypercall args?
From: "Jan Beulich" <JBeulich@xxxxxxxxxx>
Date: Fri, 12 Nov 2010 09:45:11 +0000
Cc: xen-devel@xxxxxxxxxxxxxxxxxxx
Delivery-date: Fri, 12 Nov 2010 01:46:06 -0800
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
>>> On 11.11.10 at 21:08, Keir Fraser <keir@xxxxxxx> 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.

This works in the context os do_memory_op(), which already has
a way to encode a continuation. For other hypercalls (accessible
to HVM guests) this may not be as simple, and all of them are
potentially running into this same problem.

Furthermore, even for the do_memory_op() one, encoding a
continuation for a failure of copying in the arguments is clearly
acceptable (if no other solution can be found), but unwinding
the whole operation when copying out the results fails is at
least undesirable (and can lead to a live lock). So I think a
general (hopefully transparent to the individual hypercall
handlers) solution needs to be found, and a word on the
general issue from the original paging code authors (and their
thoughts of it when designing the whole thing) would be very
much appreciated.


Xen-devel mailing list