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

["Jan Beulich" <JBeulich@xxxxxxxxxx>]

>>> 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.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel