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

[Tim Deegan <Tim.Deegan@xxxxxxxxxx>]

At 11:55 +0000 on 15 Nov (1289822118), Keir Fraser wrote:
> 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.

Right, I see.  You're suggesting that we code up a sort of setjmp() that
can be called in the __copy function, which will deschedule the vcpu and
allow it to be rescheduled back where it was.  Sounds ideal.  Will it
need per-vcpu stacks? (and will they, in turn, use order>0 allocations? :))

We'll have to audit the __copy functions to make sure they're not called
with locks held.  Sounds more fun than the alternative, I guess.

I think the ioreq code would be another candidate for tidying up if we
had such a mechanism.  Presumably some of the current users of
hypercall_create_continuation() would benefit too.

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

Good point.

Tim.

-- 
Tim Deegan <Tim.Deegan@xxxxxxxxxx>
Principal Software Engineer, Xen Platform Team
Citrix Systems UK Ltd.  (Company #02937203, SL9 0BG)

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