From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932367Ab1KGMn7 (ORCPT ); Mon, 7 Nov 2011 07:43:59 -0500 Received: from li9-11.members.linode.com ([67.18.176.11]:57587 "EHLO test.thunk.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753835Ab1KGMn5 (ORCPT ); Mon, 7 Nov 2011 07:43:57 -0500 Date: Mon, 7 Nov 2011 07:43:51 -0500 From: "Ted Ts'o" To: Pekka Enberg Cc: Avi Kivity , Sasha Levin , Gerd Hoffmann , "kvm@vger.kernel.org list" , qemu-devel Developers , "linux-kernel@vger.kernel.org List" , Alexander Graf , Blue Swirl , =?iso-8859-1?Q?Am=E9rico?= Wang , Ingo Molnar , Linus Torvalds Subject: Re: [Qemu-devel] [PATCH] KVM: Add wrapper script around QEMU to test kernels Message-ID: <20111107124351.GB24685@thunk.org> Mail-Followup-To: Ted Ts'o , Pekka Enberg , Avi Kivity , Sasha Levin , Gerd Hoffmann , "kvm@vger.kernel.org list" , qemu-devel Developers , "linux-kernel@vger.kernel.org List" , Alexander Graf , Blue Swirl , =?iso-8859-1?Q?Am=E9rico?= Wang , Ingo Molnar , Linus Torvalds References: <4EB67D17.7000701@redhat.com> <4EB680D9.2070706@redhat.com> <877C82F4-F07C-44AA-8722-3AF57CFC4597@suse.de> <4EB7B1A9.9000409@redhat.com> <4EB7CE71.50401@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: tytso@thunk.org X-SA-Exim-Scanned: No (on test.thunk.org); SAEximRunCond expanded to false Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Nov 07, 2011 at 02:29:45PM +0200, Pekka Enberg wrote: > So what do you think about perf then? The amount of code that talks to > the kernel is much smaller than that of the KVM tool. I think it's a mess, because it's never clear whether perf needs to be upgraded when I upgrade the kernel, or vice versa. This is why I keep harping on the interface issues. Fortunately it seems less likely (since perf doesn't run with privileges) that security fixes will need to be released for perf, but if it did, given the typical regression testing requirements that many distributions have, and given that most distro packaging tools assume that all binaries from a single source package come from a single version of that source package, I predict you will hear screams from the distro release engineers. And by the way, there are use cases, where the guest OS kernel and root on the guest OS are not available to the untrusted users, where the userspace KVM program would be part of the security perimeter, and were security releases to the KVM part of the tool might very well be necessary, and it would be unfortunate if that forced the release of new kernel packages each time security fixes are needed to the kvm-tool userspace. Might kvm-tool be more secure than qemu? Quite possibly, given that it's going to do less than qemu. But please note that I've not been arguing that kvm-tool shouldn't be done; just that it not be included in the kernel sources. Just as sparse is not bundled into the kernel sources, for crying out loud! - Ted From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ted Ts'o Subject: Re: [PATCH] KVM: Add wrapper script around QEMU to test kernels Date: Mon, 7 Nov 2011 07:43:51 -0500 Message-ID: <20111107124351.GB24685@thunk.org> References: <4EB67D17.7000701@redhat.com> <4EB680D9.2070706@redhat.com> <877C82F4-F07C-44AA-8722-3AF57CFC4597@suse.de> <4EB7B1A9.9000409@redhat.com> <4EB7CE71.50401@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Alexander Graf , "kvm@vger.kernel.org list" , qemu-devel Developers , Sasha Levin , "linux-kernel@vger.kernel.org List" , Blue Swirl , Gerd Hoffmann , =?iso-8859-1?Q?Am=E9rico?= Wang , Ingo Molnar , Linus Torvalds , Avi Kivity To: Pekka Enberg Return-path: Content-Disposition: inline In-Reply-To: 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 On Mon, Nov 07, 2011 at 02:29:45PM +0200, Pekka Enberg wrote: > So what do you think about perf then? The amount of code that talks to > the kernel is much smaller than that of the KVM tool. I think it's a mess, because it's never clear whether perf needs to be upgraded when I upgrade the kernel, or vice versa. This is why I keep harping on the interface issues. Fortunately it seems less likely (since perf doesn't run with privileges) that security fixes will need to be released for perf, but if it did, given the typical regression testing requirements that many distributions have, and given that most distro packaging tools assume that all binaries from a single source package come from a single version of that source package, I predict you will hear screams from the distro release engineers. And by the way, there are use cases, where the guest OS kernel and root on the guest OS are not available to the untrusted users, where the userspace KVM program would be part of the security perimeter, and were security releases to the KVM part of the tool might very well be necessary, and it would be unfortunate if that forced the release of new kernel packages each time security fixes are needed to the kvm-tool userspace. Might kvm-tool be more secure than qemu? Quite possibly, given that it's going to do less than qemu. But please note that I've not been arguing that kvm-tool shouldn't be done; just that it not be included in the kernel sources. Just as sparse is not bundled into the kernel sources, for crying out loud! - Ted From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:38511) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RNOYR-0000Ls-Ko for qemu-devel@nongnu.org; Mon, 07 Nov 2011 07:44:00 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RNOYQ-0004iz-CM for qemu-devel@nongnu.org; Mon, 07 Nov 2011 07:43:59 -0500 Received: from li9-11.members.linode.com ([67.18.176.11]:33251 helo=test.thunk.org) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RNOYQ-0004iq-66 for qemu-devel@nongnu.org; Mon, 07 Nov 2011 07:43:58 -0500 Date: Mon, 7 Nov 2011 07:43:51 -0500 From: Ted Ts'o Message-ID: <20111107124351.GB24685@thunk.org> References: <4EB67D17.7000701@redhat.com> <4EB680D9.2070706@redhat.com> <877C82F4-F07C-44AA-8722-3AF57CFC4597@suse.de> <4EB7B1A9.9000409@redhat.com> <4EB7CE71.50401@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Subject: Re: [Qemu-devel] [PATCH] KVM: Add wrapper script around QEMU to test kernels List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Pekka Enberg Cc: Alexander Graf , "kvm@vger.kernel.org list" , qemu-devel Developers , Sasha Levin , "linux-kernel@vger.kernel.org List" , Blue Swirl , Gerd Hoffmann , =?iso-8859-1?Q?Am=E9rico?= Wang , Ingo Molnar , Linus Torvalds , Avi Kivity On Mon, Nov 07, 2011 at 02:29:45PM +0200, Pekka Enberg wrote: > So what do you think about perf then? The amount of code that talks to > the kernel is much smaller than that of the KVM tool. I think it's a mess, because it's never clear whether perf needs to be upgraded when I upgrade the kernel, or vice versa. This is why I keep harping on the interface issues. Fortunately it seems less likely (since perf doesn't run with privileges) that security fixes will need to be released for perf, but if it did, given the typical regression testing requirements that many distributions have, and given that most distro packaging tools assume that all binaries from a single source package come from a single version of that source package, I predict you will hear screams from the distro release engineers. And by the way, there are use cases, where the guest OS kernel and root on the guest OS are not available to the untrusted users, where the userspace KVM program would be part of the security perimeter, and were security releases to the KVM part of the tool might very well be necessary, and it would be unfortunate if that forced the release of new kernel packages each time security fixes are needed to the kvm-tool userspace. Might kvm-tool be more secure than qemu? Quite possibly, given that it's going to do less than qemu. But please note that I've not been arguing that kvm-tool shouldn't be done; just that it not be included in the kernel sources. Just as sparse is not bundled into the kernel sources, for crying out loud! - Ted