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: Sat, 21 Apr 2012 09:23:50 +0200 Message-ID: <4F926086.3020307@web.de> References: <4F67B4C9.3010502@redhat.com> <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> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigD4DA8C4C98448D2132C91878" Cc: "Liu, Jinsong" , "qemu-devel@nongnu.org" , "kvm@vger.kernel.org" , Avi Kivity To: Eduardo Habkost Return-path: Received: from fmmailgate07.web.de ([217.72.192.248]:35110 "EHLO fmmailgate07.web.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753579Ab2DUHYI (ORCPT ); Sat, 21 Apr 2012 03:24:08 -0400 Received: from moweb002.kundenserver.de (moweb002.kundenserver.de [172.19.20.108]) by fmmailgate07.web.de (Postfix) with ESMTP id AA55A11F4169 for ; Sat, 21 Apr 2012 09:23:56 +0200 (CEST) In-Reply-To: <20120420153656.GX3169@otherpad.lan.raisama.net> Sender: kvm-owner@vger.kernel.org List-ID: This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigD4DA8C4C98448D2132C91878 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 2012-04-20 17:36, Eduardo Habkost wrote: > On Fri, Apr 20, 2012 at 05:19:17PM +0200, Jan Kiszka wrote: >> On 2012-04-20 17:00, Eduardo Habkost wrote: >>> On Fri, Apr 20, 2012 at 12:12:38PM +0200, Jan Kiszka wrote: >>>> On 2012-04-19 22:03, Eduardo Habkost wrote: >>>>> Jan/Avi: ping? >>>>> >>>>> I would like to get this ABI detail clarified so it can be implemen= ted >>>>> the right way on Qemu and KVM. >>>>> >>>>> My proposal is to simply add tsc-deadline to the data returned by >>>>> GET_SUPPORTED_CPUID, making KVM_CAP_TSC_DEADLINE_TIMER unnecessary.= >>>>> >>>> >>>> IIRC, there were problems with this model to exclude that the featur= e >>>> gets reported this way without ensuring that in-kernel irqchip is >>>> actually activated. Please browse the discussions, it should be >>>> documented there. >>> >>> The flag was never added to GET_SUPPORTED_CPUID on any of the git >>> repositories I have checked, and I don't see that being done anywhere= on >>> my KVM mailing list archives, either. So I don't see how we could hav= e >>> had issues with GET_SUPPORTED_CPUID, if it was never present on the >>> code. >>> >>> What was present on the code before the fix, was coded that >>> unconditinally enabled the flag even if Qemu never asked for it, and >>> that really was wrong. >>> >>> GET_SUPPORTED_CPUID doesn't enable any flag: it just tells userspace >>> that the hardware and KVM supports the feature (and, surprise, this i= s >>> exactly what KVM_CAP_TSC_DEADLINE_TIMER means too, isn't it?). It's u= p >>> to userspace to enable the CPUID bits according to user requirements = and >>> userspace capabilities (in other words: only when userspace knows it = is >>> safe because the in-kernel irqchip is enabled). >>> >>> If the above is not what GET_SUPPORTED_CPUID means, I would like to g= et >>> that clarified, so I can submit an updated to KVM API documentation. >> >> Does old userspace filter out flags from GET_SUPPORTED_CPUID that it >> does not understand? >=20 > It's even more strict than that: it only enables what was explicitly > enabled on the CPU model asked by the user. >=20 > But: >=20 > The only exception is "-cpu host", that tries to enable everything, eve= n > flags Qemu never heard of, and that is something that may require some > changes on the API design (or at least documentation clarifications). >=20 > Today "-cpu host" can't differentiate (A) "a feature that KVM supports > and emulate by itself and can be enabled without any support from > userspace" and (B) "a feature that KVM supports but need support from > userspace to be enabled". I am sure we will be able to find multiple > examples of (B) inside the flags returned by GET_SUPPORTED_CPUID today.= The problem remains that exposing TSC_DEADLINE via SUPPORTED_CPUID is wrong in case userspace doesn't select the in-kernel APIC. The kernel does _nothing_ about emulating the flag if userspace provides the APIC, so it must not expose this feature. Even if this had no practical impact (but it has: old qemu[-kvm] + userspace APIC + -cpu host), it would still be semantically broken. >=20 > We could decide to never add any new flag to GET_SUPPORTED_CPUID if it > requires additional userspace support to work, from now on, and create > new KVM_CAP_* flags for them. But, we really want to do that for almost= > every new CPUID feature bit in the future? Most CPU features do not depend on our in-kernel irqchips. But if there is something to simplify in retrieving information about such "conditional features", let's do it. >=20 > We also have the problem of defining what "requires support from > userspace to work" means: I am not sure this has the same meaning for > everybody. Many new features require userspace support only for > migration, and nothing else, but some users don't need migration to > work. Do those features qualify as (A), or as (B)? "Works for most user" also means "breaks for some". And that is a bug, isn't it? Jan --------------enigD4DA8C4C98448D2132C91878 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk+SYIkACgkQitSsb3rl5xQWBgCfQ0zY6zJMZuIHH/Lm0YxgFiJ8 zbQAn2VnzQ7Z5ibYfnmDRk7frcpb9AW0 =ojyU -----END PGP SIGNATURE----- --------------enigD4DA8C4C98448D2132C91878--