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

[Keir Fraser <keir@xxxxxxx>]

On 15/11/2010 10:49, "Tim Deegan" <Tim.Deegan@xxxxxxxxxx> wrote:

>> We're talking about copy_to/from_guest, and friends, here.
> 
> Oh sorry, I had lost the context there.
> 
> Yes, for those the plan was just to pause and retry, just like all other
> cases where Xen needs to access guest memory.

Could you expand on what you mean by pause and retry? As that's what I think
should be implemented, and involves sleeping in hypervisor context afaics,
which has led us to the current point in the discussion.

> We hadn't particularly
> considered the case of large hypercall arguments that aren't all read
> up-front.  How many cases of that are there?  A bit of reordering on the
> memory-operation hypercalls could presuambly let them be preempted and
> restart further in mid-operation next time.  (IIRC the compat code
> already does something like this).

The issue is that there are hundreds of uses of the guest-accessor macros.
Every single one would need updating to handle the paged-out-so-retry case,
unless we can hide that *inside* the accessor macros themselves. It's a huge
job, not to mention the bug tail on rarely-executed error paths.

Consider also the copy_to_* writeback case at the end of a hypercall. You've
done the potentially non-idempotent work, you have some state cached in
hypervisor regs/stack/heap and want to push it out to guest memory. The
guest target memory is paged out. How do you encode the continuation for the
dozens of cases like this without tearing your hair out?

I suppose *maybe* you could check-and-pin all memory that might be accessed
before the meat of a hypercall begins. That seems a fragile pain in the neck
too however.

 -- Keir



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