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

[Michael Tokarev <mjt@tls.msk.ru>]

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.

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.

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.

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.

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

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

Thanks!

/mjt