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

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

On 2011-02-23 14:15, Michael Tokarev wrote:
> 23.02.2011 15:58, Jan Kiszka wrote:
>> On 2011-02-23 12:42, Michael Tokarev wrote:
> []
>>>> - kvm/include (latest kernel headers) *)
>>>
>>> This directory is always used (in configure)
>>> unless -kerneldir is specified - who uses that
>>> nowadays?  I dunno.
>>
>> It may not be relevant to distros, provided they manage to keep their
>> /usr/include/linux stuff in sync with the kernel they ship. But if you
>> build qemu-kvm for a kernel (or kvm-kmod) that is more recent than your
>> user space headers, this matters.
> 
> 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.

> 
>  1) qemu-kvm userspace actually checks a feature before
>     using it, and omits some code if the feature isn't
>     available.  This means tons of #ifdefs, for a very
>     little gain,
> 
>  2) kernel interface stays backward-compatible, and
> 
>  3) the headers included in qemu-kvm tarball actually
>     matches the feature set in the userspace part.
> 
> Using more RECENT kernel headers to build userspace which
> don't know about the more recent features anyway should
> result in exactly the same binary, there's no reason to
> use more recent headers.
> 
>>>> *) This should really be discussed upstream again: Carry private copy of
>>>> kvm headers or rely on distro / kvm-kmod to provide required defines,
>>>> types etc.? I'm more and more in favor of option 1.
>>>
>>> Yes indeed, having current defines of all the features
>>> we actually support is a good idea.
> 
> That's the key: current features we actually support.
> If kernel headers (be them embedded into the userspace
> tarball or already installed on the system or headers
> from just built kernel.org git tree) define less than
> that, we either have tons of #ifdefs or just fail at
> build/configure time telling "use more recent headers".
> If kernel headers define more than we can understand,
> we just ignore the rest...

Right. Kernel headers tend to change in a way that is build-wise
backward compatible.

> 
>> Would you like to propose this upstream in form of a patch series (that
>> demonstrates its usefulness by dropping tones of #ifdefs)?
> 
> ..unless I completely missed the point.  Which upstream
> you're talking about -- qemu or kernel?

This is a user space topic, and qemu is upstream in this case.

>  Where the #ifdefs
> are, what they're for currently are they really needed?

In qemu, all KVM related #ifdefs should be needed, I've recently walk
through them again and consolidated the checks. I'm not that sure about
qemu-kvm, even in my current consolidation tree. But that can be sorted
out separately (e.g. while porting more feature upstream, cleaning them
up at this chance).

> 
> 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.

Jan

-- 
Siemens AG, Corporate Technology, CT T DE IT 1
Corporate Competence Center Embedded Linux