From mboxrd@z Thu Jan 1 00:00:00 1970 From: Eduardo Habkost Subject: Semantics of "-cpu host" (was Re: [Qemu-devel] [PATCH 2/2] Expose tsc deadline timer cpuid to guest) Date: Mon, 7 May 2012 15:21:42 -0300 Message-ID: <20120507182142.GD16951@otherpad.lan.raisama.net> References: <4F913696.20301@siemens.com> <20120420150005.GW3169@otherpad.lan.raisama.net> <4F917E75.2080003@siemens.com> <20120420153656.GX3169@otherpad.lan.raisama.net> <4F926086.3020307@web.de> <20120423144818.GA3169@otherpad.lan.raisama.net> <4F9583DD.10807@siemens.com> <20120423200214.GG3169@otherpad.lan.raisama.net> <4F96CF9F.9060302@siemens.com> <20120424171925.GT3169@otherpad.lan.raisama.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Jan Kiszka , "qemu-devel@nongnu.org" , "kvm@vger.kernel.org" , Avi Kivity To: Andre Przywara Return-path: Received: from mx1.redhat.com ([209.132.183.28]:46806 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754103Ab2EGSV3 (ORCPT ); Mon, 7 May 2012 14:21:29 -0400 Content-Disposition: inline In-Reply-To: <20120424171925.GT3169@otherpad.lan.raisama.net> Sender: kvm-owner@vger.kernel.org List-ID: Andre? Are you able to help to answer the question below? I would like to clarify what's the expected behavior of "-cpu host" to be able to continue working on it. I believe the code will need to be fixed on either case, but first we need to figure out what are the expectations/requirements, to know _which_ changes will be needed. On Tue, Apr 24, 2012 at 02:19:25PM -0300, Eduardo Habkost wrote: > (CCing Andre Przywara, in case he can help to clarify what's the > expected meaning of "-cpu host") > [...] > I am not sure I understand what you are proposing. Let me explain the > use case I am thinking about: > > - Feature FOO is of type (A) (e.g. just a new instruction set that > doesn't require additional userspace support) > - User has a Qemu vesion that doesn't know anything about feature FOO > - User gets a new CPU that supports feature FOO > - User gets a new kernel that supports feature FOO (i.e. has FOO in > GET_SUPPORTED_CPUID) > - User does _not_ upgrade Qemu. > - User expects to get feature FOO enabled if using "-cpu host", without > upgrading Qemu. > > The problem here is: to support the above use-case, userspace need a > probing mechanism that can differentiate _new_ (previously unknown) > features that are in group (A) (safe to blindly enable) from features > that are in group (B) (that can't be enabled without an userspace > upgrade). > > In short, it becomes a problem if we consider the following case: > > - Feature BAR is of type (B) (it can't be enabled without extra > userspace support) > - User has a Qemu version that doesn't know anything about feature BAR > - User gets a new CPU that supports feature BAR > - User gets a new kernel that supports feature BAR (i.e. has BAR in > GET_SUPPORTED_CPUID) > - User does _not_ upgrade Qemu. > - User simply shouldn't get feature BAR enabled, even if using "-cpu > host", otherwise Qemu would break. > > If userspace always limited itself to features it knows about, it would > be really easy to implement the feature without any new probing > mechanism from the kernel. But that's not how I think users expect "-cpu > host" to work. Maybe I am wrong, I don't know. I am CCing Andre, who > introduced the "-cpu host" feature, in case he can explain what's the > expected semantics on the cases above. > -- Eduardo From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:42955) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SRSYr-00081z-LQ for qemu-devel@nongnu.org; Mon, 07 May 2012 14:21:31 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1SRSYp-0004m2-No for qemu-devel@nongnu.org; Mon, 07 May 2012 14:21:29 -0400 Received: from mx1.redhat.com ([209.132.183.28]:39642) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SRSYp-0004lf-FQ for qemu-devel@nongnu.org; Mon, 07 May 2012 14:21:27 -0400 Date: Mon, 7 May 2012 15:21:42 -0300 From: Eduardo Habkost Message-ID: <20120507182142.GD16951@otherpad.lan.raisama.net> References: <4F913696.20301@siemens.com> <20120420150005.GW3169@otherpad.lan.raisama.net> <4F917E75.2080003@siemens.com> <20120420153656.GX3169@otherpad.lan.raisama.net> <4F926086.3020307@web.de> <20120423144818.GA3169@otherpad.lan.raisama.net> <4F9583DD.10807@siemens.com> <20120423200214.GG3169@otherpad.lan.raisama.net> <4F96CF9F.9060302@siemens.com> <20120424171925.GT3169@otherpad.lan.raisama.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20120424171925.GT3169@otherpad.lan.raisama.net> Subject: [Qemu-devel] Semantics of "-cpu host" (was Re: [PATCH 2/2] Expose tsc deadline timer cpuid to guest) List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Andre Przywara Cc: Jan Kiszka , "qemu-devel@nongnu.org" , "kvm@vger.kernel.org" , Avi Kivity Andre? Are you able to help to answer the question below? I would like to clarify what's the expected behavior of "-cpu host" to be able to continue working on it. I believe the code will need to be fixed on either case, but first we need to figure out what are the expectations/requirements, to know _which_ changes will be needed. On Tue, Apr 24, 2012 at 02:19:25PM -0300, Eduardo Habkost wrote: > (CCing Andre Przywara, in case he can help to clarify what's the > expected meaning of "-cpu host") > [...] > I am not sure I understand what you are proposing. Let me explain the > use case I am thinking about: > > - Feature FOO is of type (A) (e.g. just a new instruction set that > doesn't require additional userspace support) > - User has a Qemu vesion that doesn't know anything about feature FOO > - User gets a new CPU that supports feature FOO > - User gets a new kernel that supports feature FOO (i.e. has FOO in > GET_SUPPORTED_CPUID) > - User does _not_ upgrade Qemu. > - User expects to get feature FOO enabled if using "-cpu host", without > upgrading Qemu. > > The problem here is: to support the above use-case, userspace need a > probing mechanism that can differentiate _new_ (previously unknown) > features that are in group (A) (safe to blindly enable) from features > that are in group (B) (that can't be enabled without an userspace > upgrade). > > In short, it becomes a problem if we consider the following case: > > - Feature BAR is of type (B) (it can't be enabled without extra > userspace support) > - User has a Qemu version that doesn't know anything about feature BAR > - User gets a new CPU that supports feature BAR > - User gets a new kernel that supports feature BAR (i.e. has BAR in > GET_SUPPORTED_CPUID) > - User does _not_ upgrade Qemu. > - User simply shouldn't get feature BAR enabled, even if using "-cpu > host", otherwise Qemu would break. > > If userspace always limited itself to features it knows about, it would > be really easy to implement the feature without any new probing > mechanism from the kernel. But that's not how I think users expect "-cpu > host" to work. Maybe I am wrong, I don't know. I am CCing Andre, who > introduced the "-cpu host" feature, in case he can explain what's the > expected semantics on the cases above. > -- Eduardo