From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1757408Ab2BHRLg (ORCPT ); Wed, 8 Feb 2012 12:11:36 -0500 Received: from lxorguk.ukuu.org.uk ([81.2.110.251]:60302 "EHLO lxorguk.ukuu.org.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1756995Ab2BHRLf (ORCPT ); Wed, 8 Feb 2012 12:11:35 -0500 Date: Wed, 8 Feb 2012 17:12:49 +0000 From: Alan Cox To: Scott Wood Cc: Anthony Liguori , qemu-devel , linux-kernel , Eric Northup , KVM list , Avi Kivity Subject: Re: [Qemu-devel] [RFC] Next gen kvm api Message-ID: <20120208171249.1b1eb5d0@pyramind.ukuu.org.uk> In-Reply-To: <4F32AAA7.2040203@freescale.com> References: <4F2AB552.2070909@redhat.com> <4F2C6517.3040203@codemonkey.ws> <4F302E0D.20302@freescale.com> <4F3118EA.7040302@codemonkey.ws> <4F32AAA7.2040203@freescale.com> X-Mailer: Claws Mail 3.8.0 (GTK+ 2.24.8; x86_64-redhat-linux-gnu) Face: iVBORw0KGgoAAAANSUhEUgAAADAAAAAwBAMAAAClLOS0AAAAFVBMVEWysKsSBQMIAwIZCwj///8wIhxoRDXH9QHCAAABeUlEQVQ4jaXTvW7DIBAAYCQTzz2hdq+rdg494ZmBeE5KYHZjm/d/hJ6NfzBJpp5kRb5PHJwvMPMk2L9As5Y9AmYRBL+HAyJKeOU5aHRhsAAvORQ+UEgAvgddj/lwAXndw2laEDqA4x6KEBhjYRCg9tBFCOuJFxg2OKegbWjbsRTk8PPhKPD7HcRxB7cqhgBRp9Dcqs+B8v4CQvFdqeot3Kov6hBUn0AJitrzY+sgUuiA8i0r7+B3AfqKcN6t8M6HtqQ+AOoELCikgQSbgabKaJW3kn5lBs47JSGDhhLKDUh1UMipwwinMYPTBuIBjEclSaGZUk9hDlTb5sUTYN2SFFQuPe4Gox1X0FZOufjgBiV1Vls7b+GvK3SU4wfmcGo9rPPQzgIabfj4TYQo15k3bTHX9RIw/kniir5YbtJF4jkFG+dsDK1IgE413zAthU/vR2HVMmFUPIHTvF6jWCpFaGw/A3qWgnbxpSm9MSmY5b3pM1gvNc/gQfwBsGwF0VCtxZgAAAAASUVORK5CYII= Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org > If the fd overhead really is a problem, perhaps the fd could be retained > for setup operations, and omitted only on calls that require a vcpu to > have been already set up on the current thread? Quite frankly I'd like to have an fd because it means you've got a meaningful way of ensuring that id reuse problems go away. You open a given id and keep a handle to it, if the id gets reused then your handle will be tied to the old one so you can fail the requests. Without an fd it's near impossible to get this right. The Unix/Linux model is open an object, use it, close it. I see no reason not to do that. Also the LSM hooks apply to file objects mostly, so its a natural fit on top *IF* you choose to use them. Finally you can pass file handles around between processes - do that any other way 8) Alan From mboxrd@z Thu Jan 1 00:00:00 1970 From: Alan Cox Subject: Re: [RFC] Next gen kvm api Date: Wed, 8 Feb 2012 17:12:49 +0000 Message-ID: <20120208171249.1b1eb5d0@pyramind.ukuu.org.uk> References: <4F2AB552.2070909@redhat.com> <4F2C6517.3040203@codemonkey.ws> <4F302E0D.20302@freescale.com> <4F3118EA.7040302@codemonkey.ws> <4F32AAA7.2040203@freescale.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: KVM list , qemu-devel , linux-kernel , Avi Kivity , Eric Northup To: Scott Wood Return-path: In-Reply-To: <4F32AAA7.2040203@freescale.com> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: qemu-devel-bounces+gceq-qemu-devel=gmane.org@nongnu.org Sender: qemu-devel-bounces+gceq-qemu-devel=gmane.org@nongnu.org List-Id: kvm.vger.kernel.org > If the fd overhead really is a problem, perhaps the fd could be retained > for setup operations, and omitted only on calls that require a vcpu to > have been already set up on the current thread? Quite frankly I'd like to have an fd because it means you've got a meaningful way of ensuring that id reuse problems go away. You open a given id and keep a handle to it, if the id gets reused then your handle will be tied to the old one so you can fail the requests. Without an fd it's near impossible to get this right. The Unix/Linux model is open an object, use it, close it. I see no reason not to do that. Also the LSM hooks apply to file objects mostly, so its a natural fit on top *IF* you choose to use them. Finally you can pass file handles around between processes - do that any other way 8) Alan From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:60863) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RvB3M-0000dk-Hv for qemu-devel@nongnu.org; Wed, 08 Feb 2012 12:11:36 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RvB3K-0004bv-AF for qemu-devel@nongnu.org; Wed, 08 Feb 2012 12:11:32 -0500 Received: from lxorguk.ukuu.org.uk ([81.2.110.251]:53982) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RvB3J-0004au-W4 for qemu-devel@nongnu.org; Wed, 08 Feb 2012 12:11:30 -0500 Date: Wed, 8 Feb 2012 17:12:49 +0000 From: Alan Cox Message-ID: <20120208171249.1b1eb5d0@pyramind.ukuu.org.uk> In-Reply-To: <4F32AAA7.2040203@freescale.com> References: <4F2AB552.2070909@redhat.com> <4F2C6517.3040203@codemonkey.ws> <4F302E0D.20302@freescale.com> <4F3118EA.7040302@codemonkey.ws> <4F32AAA7.2040203@freescale.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [RFC] Next gen kvm api List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Scott Wood Cc: KVM list , qemu-devel , linux-kernel , Avi Kivity , Eric Northup > If the fd overhead really is a problem, perhaps the fd could be retained > for setup operations, and omitted only on calls that require a vcpu to > have been already set up on the current thread? Quite frankly I'd like to have an fd because it means you've got a meaningful way of ensuring that id reuse problems go away. You open a given id and keep a handle to it, if the id gets reused then your handle will be tied to the old one so you can fail the requests. Without an fd it's near impossible to get this right. The Unix/Linux model is open an object, use it, close it. I see no reason not to do that. Also the LSM hooks apply to file objects mostly, so its a natural fit on top *IF* you choose to use them. Finally you can pass file handles around between processes - do that any other way 8) Alan