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

[Tim Deegan <Tim.Deegan@xxxxxxxxxx>]

At 10:09 +0000 on 15 Nov (1289815777), Keir Fraser wrote:
> On 15/11/2010 09:53, "Jan Beulich" <JBeulich@xxxxxxxxxx> wrote:
> 
> >> Maybe Patrick can comment too, but my recollection of discussing this is
> >> that we would have to propagate failures caused by paging at least as
> >> far as the dom0 kernel, because otherwise a single-vcpu dom0 kernel
> >> could deadlock with its one vcpu stuck in a hypercall (or continually
> >> having it preempted and retried) and the paging binary that would
> >> unstick it never getting scheduled.
> > 
> > How's Dom0 involved here? The hypercall arguments live in
> > guest memory.
> 
> Yes, and you'd never turn on paging for dom0 itself. That would never work!

:) No, the issue is if dom0 (or whichever dom the pager lives in) is
trying an operation on domU's memory that hits a paged-out page
(e.g. qemu or similar is mapping it) with its only vpcu - you can't
just block or spin.  You need to let dom0 schedule the pager process. 

> Changing every user of the guest accessor macros to retry via guest space is
> really not tenable. We'd never get all the bugs out.

Right now, I can't see another way of doing it.  Grants can be handled
by shadowing the guest grant table and pinning granted frames so the
block happens in domU (performance-- but you're already paging, right?)
but what about qemu, xenctx, save/restore...?

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