From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jan Kiszka Subject: Re: [Qemu-devel] [PATCH 2/2] Expose tsc deadline timer cpuid to guest Date: Mon, 23 Apr 2012 18:31:25 +0200 Message-ID: <4F9583DD.10807@siemens.com> References: <20120320133314.GV9375@otherpad.lan.raisama.net> <20120323134607.GF9375@otherpad.lan.raisama.net> <20120419200331.GB19463@otherpad.lan.raisama.net> <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> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "Liu, Jinsong" , "qemu-devel@nongnu.org" , "kvm@vger.kernel.org" , Avi Kivity To: Eduardo Habkost Return-path: Received: from david.siemens.de ([192.35.17.14]:31110 "EHLO david.siemens.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753525Ab2DWQbf (ORCPT ); Mon, 23 Apr 2012 12:31:35 -0400 In-Reply-To: <20120423144818.GA3169@otherpad.lan.raisama.net> Sender: kvm-owner@vger.kernel.org List-ID: On 2012-04-23 16:48, Eduardo Habkost wrote: > Trying to summarize the points above: > > Groups (A) and (B) are: > > A) a feature that KVM supports and emulate by itself and can be enabled > by userspace blindly, without requiring any additional userspace > code to work. > B) a feature that KVM supports but need support from userspace to work. > > We have to differentiate those two groups somehow, otherwise "-cpu host" > will always risk being unstable (in case we can't identify group (B) and > end up enabling a feature that will break) or useless (if group (A) is > considered always empty). > > (If you think this two-group model is not sufficient, please let me know.) > > Note that I am discussing two things above: > > - Whether GET_SUPPORTED_CPUID should expose only features from group > (A), or group (B) too. > - One problem here is that today GET_SUPPORTED_CPUIDS have many > examples of (B) features inside it. Should we stop doing that? We have exactly two for the category that I was concerned about: TSC deadline and X2APIC. The latter is already exposed unconditionally, even if the kernel does not provide emulation. So, you are right, TSC deadline is not a new scenario. > - TSC-deadline is the first case where we are _not_ doing that. It > is the first CPU feature in KVM that can be enabled by userspace > (as long as userspace does the proper setup), but it's not > included on GET_SUPPORTED_CPUIDs. > - Even the current documentation implies that group (B) is included: > > "This ioctl returns x86 cpuid features which are supported by both > the hardware and kvm. Userspace can use the information returned by > this ioctl to construct cpuid information (for KVM_SET_CPUID2) that > is consistent with hardware, kernel, and userspace capabilities, and > ^^^^^^^^^^^^^^^^^^^^^^^^^^ > with user requirements (for example, the user may wish to constrain > cpuid to emulate older hardware, or for feature consistency across a > cluster)." > > In the specific case of TSC-deadline, I consider "Qemu knowing that > TSC-deadline can be enabled only if in-kernel irqchip is enabled" as > an "userpace capability". > > - How to precisely define the groups (A) and (B)? > - "requires additional code only if migration is required" qualifies > as (B) or (A)? > - "requires in-kernel irqchip to be enabled to work" qualifies as (B), > doesn't it? My problem is that features like X2APIC and TSC deadline are exposed by the kernel without "contributing" to them (if in-kernel irqchip is off). However, that was how I interpreted this GET_SUPPORTED_CPUID. In fact, it is used as "kernel or hardware does not _prevent_" already. And in that sense, it's ok to enable even features that are not in kernel/hardware hands. We should point out this fact in the documentation. Jan -- Siemens AG, Corporate Technology, CT T DE IT 1 Corporate Competence Center Embedded Linux