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] [RFC PATCH 28/33] Add Xen grant table support

To: Chris Wright <chrisw@xxxxxxxxxxxx>
Subject: Re: [Xen-devel] [RFC PATCH 28/33] Add Xen grant table support
From: Harry Butterworth <harry@xxxxxxxxxxxxxxxxxxxxxxxxxxxxx>
Date: Wed, 19 Jul 2006 11:04:10 +0100
Cc: Andrew Morton <akpm@xxxxxxxx>, Zachary Amsden <zach@xxxxxxxxxx>, Jeremy Fitzhardinge <jeremy@xxxxxxxx>, xen-devel@xxxxxxxxxxxxxxxxxxx, virtualization@xxxxxxxxxxxxxx, Rusty Russell <rusty@xxxxxxxxxxxxxxx>, linux-kernel@xxxxxxxxxxxxxxx, Andi Kleen <ak@xxxxxxx>, Ian Pratt <ian.pratt@xxxxxxxxxxxxx>, Christian Limpach <Christian.Limpach@xxxxxxxxxxxx>
Delivery-date: Wed, 19 Jul 2006 03:04:47 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <20060718091956.905130000@xxxxxxxxxxxx>
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/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <20060718091807.467468000@xxxxxxxxxxxx> <20060718091956.905130000@xxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
I don't think that the current grant-table API/implementation quite
meets the requirements for revocation.

Specifically I think the requirements are that:

1) When a domain starts to reclaim a set of resources it allocated for
inter-domain communication this process is guaranteed to complete
without cooperation from any other domain.

2) When a domain reclaims resources it allocated for inter-domain
communication it can't cause a page fault or other exception in any
other domain.

The current API/implementation meets the second requirement but not the

It's possible to make the current implementation meet the first
requirement if you relax it a bit and allow the superuser to kill an
offending domain via domain 0 but this expands the scope of the failure
from a single inter-domain communication channel to a whole domain which
is undesirable.

Another potential issue with grant-tables is support for efficient N-way
communication but I haven't investigated that personally.

A final point is that quite a lot of fairly tricky code is required to
combine grant-tables, event-channels and xenbus before you can create an
inter-domain communication channel which can be correctly disconnected
and reconnected across module load and unload.

It's appropriate to have a low-level API at the hypervisor because it
keeps the hypervisor as small as possible and therefore easier to audit.

But, whatever the low-level API, whether grant-tables or something which
has better support for revocation and n-way communication, I think there
needs to be a small library to implement a higher level API that is more
convenient for driver authors to use directly.

Xen-devel mailing list

<Prev in Thread] Current Thread [Next in Thread>