Re: Q: status of kvm/ subdir in qemu-kvm tarball?

[Jan Kiszka <jan.kiszka@siemens.com>]

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