From: Harry Butterworth Subject: Re: [RFC PATCH 28/33] Add Xen grant table support Date: Wed, 19 Jul 2006 11:04:10 +0100 Message-ID: <1153303451.7728.18.camel@localhost.localdomain> References: <20060718091807.467468000@sous-sol.org> <20060718091956.905130000@sous-sol.org> Mime-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <20060718091956.905130000@sous-sol.org> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Chris Wright Cc: Andrew Morton , Zachary Amsden , Jeremy Fitzhardinge , xen-devel@lists.xensource.com, virtualization@lists.osdl.org, Rusty Russell , linux-kernel@vger.kernel.org, Andi Kleen , Ian Pratt , Christian Limpach List-Id: xen-devel@lists.xenproject.org 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.