| |
|
 |
|
 |
|
|
|
| |
|
|
xen-devel
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
first.
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
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
|
|
| |
|
Home