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: "Jan Beulich" <JBeulich@xxxxxxxxxx>
Date: Fri, 12 Nov 2010 10:47:10 +0000
Cc: Olaf Hering <olaf@xxxxxxxxx>, xen-devel@xxxxxxxxxxxxxxxxxxx
Delivery-date: Fri, 12 Nov 2010 02:48:06 -0800
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <C902C5F8.9A06%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: <4CDD1AB70200007800021EB7@xxxxxxxxxxxxxxxxxx> <C902C5F8.9A06%keir@xxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
>>> On 12.11.10 at 11:22, Keir Fraser <keir@xxxxxxx> wrote:
> On 12/11/2010 09:45, "Jan Beulich" <JBeulich@xxxxxxxxxx> wrote:
>> 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.
> We will at least have to enforce that no spinlocks are held during
> copy_to/from_guest operations. That's easily enforced at least in debug
> builds of course.
> Beyond that, introducing some transparent mechanisms for sleeping in the
> hypervisor -- mutexes, wait queues, and the like -- is actually fine with
> me. Perhaps this will also help clean up the preemptible page-type-checking
> logic that you had to do some heavy lifting on?

I'm not sure it would help there - this requires voluntary
preemption rather than synchronization. But perhaps it can be
built on top of this (or results as a side effect).

> I'm happy to help work on the basic mechanism of this, if it's going to be
> useful and widely used. I reckon I could get mutexes and wait queues going
> in a couple of days. This would be the kind of framework that the paging
> mechanisms should then properly be built on.
> What do you think?

Sounds good, and you helping with this will be much appreciated
(Olaf - unless you had plans doing this yourself). Whether it's going
to be widely used I can't tell immediately - for the moment,
overcoming the paging problems seems like the only application.


Xen-devel mailing list