WARNING - OLD ARCHIVES

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/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

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

To: Tim Deegan <Tim.Deegan@xxxxxxxxxx>
Subject: Re: [Xen-devel] Re: how to handle paged hypercall args?
From: Keir Fraser <keir@xxxxxxx>
Date: Mon, 15 Nov 2010 12:17:13 +0000
Cc: Olaf Hering <olaf@xxxxxxxxx>, "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>, Patrick Colp <pjcolp@xxxxxxxxx>, Jan Beulich <JBeulich@xxxxxxxxxx>
Delivery-date: Mon, 15 Nov 2010 04:18:25 -0800
Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:user-agent:date :subject:from:to:cc:message-id:thread-topic:thread-index:in-reply-to :mime-version:content-type:content-transfer-encoding; bh=TmaprsarIshsRrjcE2J9uML4vWOb7g2YVCxje5o1KAM=; b=mY50Fg9Y/lt7qHL3vNdStCs/i6InIuG1R2KJIjvCvO9yeHIog9mpi/eIDaOi4nU+8C 3t0khLbc1glOHlIYDVAVFIMZ7htpnmhQ304kvGr8jdJXdggVbItn2d1iztqGoOq+k/NJ LdNRtR6W+1tPu18u4dobs6qgFQt8hjnwtXT0I=
Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:user-agent:date:subject:from:to:cc:message-id:thread-topic :thread-index:in-reply-to:mime-version:content-type :content-transfer-encoding; b=M7rB7PU6ONYjEW9kwzb+xe64c1a5lUmUqvIhq+Lngqdru0Le4bUy6Dz/vmPynBTY79 o7cTN76c70BVNvHHVCxa4KGtP9+WnaM6TSlmjTwiKEmL2JY5dYPL7xhH+toaGhp6T57s 0fLveEQsBnpiXhW1lh5VTB3kl2IiH+ZnLzk9Q=
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <20101115120459.GF21112@xxxxxxxxxxxxxxxxxxxxxxx>
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>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: AcuEvwi2K6exNKykL0iuiBAAfnzHLw==
Thread-topic: [Xen-devel] Re: how to handle paged hypercall args?
User-agent: Microsoft-Entourage/12.27.0.100910
On 15/11/2010 12:04, "Tim Deegan" <Tim.Deegan@xxxxxxxxxx> wrote:

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

Exactly so.

> Will it
> need per-vcpu stacks? (and will they, in turn, use order>0 allocations? :))

Of a sort. I propose to keep the per-pcpu stacks and then copy context
to/from a per-vcpu memory area for the setjmp-like behaviour. Guest call
stacks won't be very deep -- I reckon a 1kB or 2kB per-vcpu area will
suffice.

In some ways this is a backwards version of the Linux stack-handling logic,
which has a proper per-task kernel stack which is of moderate size (4kB?).
Then it has per-cpu irq stacks which are larger to deal with deep irq
nesting. We will have proper per-cpu hypervisor stacks of sufficient size to
deal with guest and irq state -- our per-vcpu 'shadow stack' will then be
the special case and only of small/moderate size to deal with shallow guest
call stacks.

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

Exactly so. Best of a bad set of options. At least we can run-time assert
this and it's not error-path only.

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

Yeah, it needs a dash of thought but I think we will be able to move in this
direction.

 -- Keir

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



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