From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jan Kiszka Subject: Re: Q: status of kvm/ subdir in qemu-kvm tarball? Date: Wed, 23 Feb 2011 15:57:04 +0100 Message-ID: <4D652040.9000309@siemens.com> References: <4D64E9C6.8000505@msgid.tls.msk.ru> <4D64F008.7050308@siemens.com> <4D64F2C0.4000609@msgid.tls.msk.ru> <4D650479.30609@siemens.com> <4D650884.3090801@msgid.tls.msk.ru> <4D650F85.10502@siemens.com> <4D651A1D.8030206@msgid.tls.msk.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: KVM list To: Michael Tokarev Return-path: Received: from david.siemens.de ([192.35.17.14]:30960 "EHLO david.siemens.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750806Ab1BWO5I (ORCPT ); Wed, 23 Feb 2011 09:57:08 -0500 In-Reply-To: <4D651A1D.8030206@msgid.tls.msk.ru> Sender: kvm-owner@vger.kernel.org List-ID: On 2011-02-23 15:30, Michael Tokarev wrote: > 23.02.2011 16:45, Jan Kiszka wrote: >> On 2011-02-23 14:15, Michael Tokarev wrote: > [] >>> It only matters if you want to build qemu-kvm for OLDER >>> kernel without support of some features which are used by >>> the userspace you're building. Provided 3 things: >> >> It also matters if you are building for a kernel more recent than the >> headers you have (wherever they came from). Think of the scenario that >> you build a recent customized kernel for you host. Then you also need to >> remember running "make header_install" and picking up those headers for >> the qemu build. > > Um. We're going in circles :) > > I mean, qemu userspace does not need kernels more recent > than it can understand. So there's no need to use > external headers instead of using a copy embedded in > the tarball - which may be not up-to-date wrt currently > running kernel or currently installed headers, but the > extra features available there wont be used anyway since > that particular qemu userspace does not understand them > anyway. Right. > > The only situation where using kernel headers not provided > by qemu itself is when you want to build qemu for older > kernel and omit some features and runtime tests. But this > is hardly a good goal to support. I don't think the goal of the #ifdefs was ever some kind of size optimization but just for the sake of avoiding build breakages. > > For the above scenario (installing a custom very recent > kernel but forgetting to run `make header_install') to > be of any use, you also need qemu userspace that is > able to use the new feature in this shiny new kernel. > > So to sum it up, we've two options (actually 3, but > 3rd isn't very interesting): > > 1) embed "recent enough" (for this version of qemu) > kernel headers and always use this copy, or > > 2) use system headers and always assume all features > we actually understand are present in there, and > fail if they're not. This can be a configure-time > check (it already is, sort of), so configure can > tell the user the minimum required version to > install. 2) is no option as the delta between a qemu version and the available headers can easily become too large (e.g. in Debian...). > > I've no preference for either of the two, first is > more convinient and second has less duplicates. > > (By "qemu" I mean either qemu or qemu-kvm, since the > two tries to become the same thing) > > [] >>> Does qemu[-kvm] want to stay compatible with older kernels, >>> or kernel headers? If yes, how old is old? >> >> Our current minimum requirement is the KVM ABI provided by 2.6.29. The >> runtime check is detecting this via the existence of certain key >> capabilities. The related build-time check takes place during configure, >> probing a list of minimally required KVM_CAPs. >> >> This last check would become obsolete if we always pick the headers from >> a qemu-local copy. Furthermore, we could drop "#ifdef KVM_CAP" around >> features that are more recent than our kernel baseline. Runtime checking >> will still be required, of course. > > That check is useful to error out and tell user if the minimum > requiriment is not satisfied. Keeping lots of ifdefs isn't useful > IMHO. That configure check already reduced the size of that forest. Or course, we could also move all inlined #ifdefs to the configure check - if we continue to allow building against different headers than the included ones. But I would prefer to avoid this in order to reduce the variations (of which one combination always break). > > So I'd say keep --with-kernelheaders, keep the checks in configure > (maybe activate them if --with-kernelheaders is specified), keep > local kernel headers which are recent enough, and remove irrelevant > #ifdefs around new API. > > I'm not sure again I understand your statement about removing > #ifdefs in the previous email -- now you say you verified that > all #ifdefs are needed. They're either needed or can be removed... ;) They are needed ATM as we allow building against any headers of >= 2.6.29. They would become obsolete if we provided the right ones in-tree. > > But that all went quite far away from dropping old cruft from > kvm/ subdir - as we found out, there are 2 useful pieces in > there, kvm_stat helper and kernel headers, so let's keep them > for now and remove the rest. > > Anyway, that's quite long "discussion" about nearly nothing... :) Well, "rm -r kvm" is a rather minor thing. But the header discussion is important IMO as we continue to see breakages in KVM builds (mostly qemu upstream) due to missing #ifdefs. That means: - we do not test all variants (because it's impractical) - people use older headers - too much effort is wasted on fixing distributed problems that can be solved centrally Jan -- Siemens AG, Corporate Technology, CT T DE IT 1 Corporate Competence Center Embedded Linux