From mboxrd@z Thu Jan 1 00:00:00 1970 From: Gleb Natapov Subject: Re: Semantics of "-cpu host" (was Re: [PATCH 2/2] Expose tsc deadline timer cpuid to guest) Date: Wed, 9 May 2012 11:14:04 +0300 Message-ID: <20120509081404.GO15960@redhat.com> References: <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> <20120507182142.GD16951@otherpad.lan.raisama.net> <20120508201441.GN4373@otherpad.lan.raisama.net> <6BF7428F-FDEF-4497-94F5-7A43BC9E1E67@suse.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Andre Przywara , Eduardo Habkost , "kvm@vger.kernel.org" , Jan Kiszka , "qemu-devel@nongnu.org" , Avi Kivity To: Alexander Graf Return-path: Content-Disposition: inline In-Reply-To: <6BF7428F-FDEF-4497-94F5-7A43BC9E1E67@suse.de> 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 Wed, May 09, 2012 at 12:07:04AM +0200, Alexander Graf wrote: > > On 08.05.2012, at 22:14, Eduardo Habkost wrote: > > > On Tue, May 08, 2012 at 02:58:11AM +0200, Alexander Graf wrote: > >> On 07.05.2012, at 20:21, Eduardo Habkost wrote: > >> > >>> > >>> 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. > >> > >> Can you think of any feature that'd go into category B? > > > > - TSC-deadline: can't be enabled unless userspace takes care to enable > > the in-kernel irqchip. > > The kernel can check if in-kernel irqchip has it enabled and otherwise mask it out, no? > How kernel should know that userspace does not emulate it? > > - x2apic: ditto. > > Same here. For user space irqchip the kernel side doesn't care. If in-kernel APIC is enabled, check for its capabilities. > Same here. Well, technically both of those features can't be implemented in userspace right now since MSRs are terminated in the kernel, but I wouldn't make it into ABI. -- Gleb. From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:59890) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SS22E-0004wg-Q1 for qemu-devel@nongnu.org; Wed, 09 May 2012 04:14:12 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1SS22C-0005jf-RB for qemu-devel@nongnu.org; Wed, 09 May 2012 04:14:10 -0400 Received: from mx1.redhat.com ([209.132.183.28]:37239) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SS22C-0005jO-JB for qemu-devel@nongnu.org; Wed, 09 May 2012 04:14:08 -0400 Date: Wed, 9 May 2012 11:14:04 +0300 From: Gleb Natapov Message-ID: <20120509081404.GO15960@redhat.com> References: <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> <20120507182142.GD16951@otherpad.lan.raisama.net> <20120508201441.GN4373@otherpad.lan.raisama.net> <6BF7428F-FDEF-4497-94F5-7A43BC9E1E67@suse.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <6BF7428F-FDEF-4497-94F5-7A43BC9E1E67@suse.de> Subject: Re: [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: Alexander Graf Cc: Andre Przywara , Eduardo Habkost , "kvm@vger.kernel.org" , Jan Kiszka , "qemu-devel@nongnu.org" , Avi Kivity On Wed, May 09, 2012 at 12:07:04AM +0200, Alexander Graf wrote: > > On 08.05.2012, at 22:14, Eduardo Habkost wrote: > > > On Tue, May 08, 2012 at 02:58:11AM +0200, Alexander Graf wrote: > >> On 07.05.2012, at 20:21, Eduardo Habkost wrote: > >> > >>> > >>> 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. > >> > >> Can you think of any feature that'd go into category B? > > > > - TSC-deadline: can't be enabled unless userspace takes care to enable > > the in-kernel irqchip. > > The kernel can check if in-kernel irqchip has it enabled and otherwise mask it out, no? > How kernel should know that userspace does not emulate it? > > - x2apic: ditto. > > Same here. For user space irqchip the kernel side doesn't care. If in-kernel APIC is enabled, check for its capabilities. > Same here. Well, technically both of those features can't be implemented in userspace right now since MSRs are terminated in the kernel, but I wouldn't make it into ABI. -- Gleb.