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


Re: [Xen-devel] [PATCH] Paging and memory sharing for HVM guests

To: Jan Beulich <JBeulich@xxxxxxxxxx>
Subject: Re: [Xen-devel] [PATCH] Paging and memory sharing for HVM guests
From: Grzegorz Milos <gm281@xxxxxxxxx>
Date: Thu, 17 Dec 2009 13:08:31 +0000
Cc: Patrick Colp <pjcolp@xxxxxxxxx>, xen-devel@xxxxxxxxxxxxxxxxxxx, Andrew Peace <Andrew.Peace@xxxxxxxxxxxxx>, Keir Fraser <keir.fraser@xxxxxxxxxxxxx>
Delivery-date: Thu, 17 Dec 2009 05:08:54 -0800
Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to:cc :content-type; bh=IIfZRWOX9NgKGS3+hvUAW5FhZfESMMajGl0msNJKcZ4=; b=oXmjM8ZcJcAuh0VU81iKy5yQU7q6VZ/eTlzN5EZJSE4jZZKGTMsw3mAC7Sq8mT+ut3 cTRvYXF6h59b7k5fycbKaO6FUqWt9KHMgiLWRLuMmgfN7JvR+s9DfSlz369m5oTfOAWQ qbq2MAuhlq+eEgyHgBxfppHezWUo6galmZOeY=
Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; b=B1qwO17lqZ9fzaRYM4vHpqTPofZpazRvaBtPHiNF50J1I4sWIozBZ7elDIcCiL5LN4 FoIqLWKx+Ra2D7QV4lAahrQVjct+1I5KklAn037q0v7jAhXv5wRj4ConfkSrQKcqDxzH ugCK3vHrmNCeN6W9/uPehQ7Z/MieP77q8IFd4=
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <4B29FE2102000078000266A6@xxxxxxxxxxxxxxxxxx>
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>
References: <db8ce2bd0912161514s7a162546gf7f5909db22e274c@xxxxxxxxxxxxxx> <4B29FE2102000078000266A6@xxxxxxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
> An overview description of the design would be nice, to have a basic
> understanding before looking at the individual patches. In particular,
> from a first brief look, I'm having the impression that only HVM guests'
> pages can be subject to paging.

Indeed. Paging and memory sharing is designed for HVM guests only. We
are compiling proper documentation for it, but we'll try to write a
short(er) overview too.

> On the Linux patches:
> Introducing another bogus failure indicator for the mmap_batch
> privcmd operations seems rather undesirable - we'll already need to
> find a backwards-compatible solution to the current (broken) or-ing
> in of 0xf0000000 (broken because MFNs can now be more than
> 28 bits wide).

Surly you mean > 30 bits wide?
Anyway, I'll let Patrick comment on that, since he is the author of
this bit of the code.

> Using msleep() with hard-coded values (in at least one case even
> contradicting the accompanying comment) seems more like a hack
> than a permanent solution. Can't there be some signaling done, or
> can't there alternatively be a polling hypercall?

We intent do use proper signalling for EAGAIN failed grant maps at
least. For example, you'll notice that I've separated the block
backend patch into two, with the
'mem_sharing_blkback_periodic_retry.patch' implementing a temporary
retry loop. Once we've got memory event interface ready, we'll replace
the loop with a mem event 'kick'. In some cases though, a simple retry
loop seem fine to me (e.g. grant maps of ring pages).

WRT to a catch-all retry loop for 'direct' foreign mappings, the idea
is that we'll provide a separate non-blocking call (which may fail
with EAGAIN) for the callers who care about performance. For the time
being a single retry loop was the quickest way to get the code out for
people to test/comment on it.

> Removing support for IOCTL_PRIVCMD_MMAP from the pv-ops
> implementation seems pretty unrelated, so should probably be a
> separate patch.

Forwarding this Q to Patrick again.

> Also, most of the patches seem to use blanks instead of tabs for
> indentation, and occasionally other non-standard formatting.

Mea culpa. I tend to have 'tab expansion' set in my editor. I'll fix
whitespace in my linux kernel patches.


Xen-devel mailing list