Re: qemu-kvm broken after ./configure --disable-kvm

[Jan Kiszka <jan.kiszka@web.de>]

[-- Attachment #1: Type: text/plain, Size: 1621 bytes --]

Avi Kivity wrote:
> Jan Kiszka wrote:
>>>> 2. Upstream does not, and it's unclear if it ever will (if we push
>>>>    recent headers into kvm-kmod, I think there is no urgent need
>>>>    anymore). At least for code to-be-pushed upstream, we must not
>>>>    rely in this anyway.
>>>>       
>>> Yes.
>>>
>>> Adding the headers to kvm-kmod.h is the right thing technically, but
>>> something tells me we'll get a lot of failures by people compiling first
>>> and installing later, rather than the sequence needed to make things
>>> work: compile and install kvm-kmod, compile and install qemu[-kvm].  Not
>>> all of the failures will be visible at compile time.
>>>
>>>     
>>
>> That could (and probably should - independent of in-tree headers) be
>> caught by making all KVM_CAPs mandatory, ie. check for the latest and
>> greatest ones during configure and drop all the #ifdefs from the code.
>>   
> 
> Not with out-of-tree headers.  qemu-kvm-0.10.x ought to build against
> Linux 2.6.27, kvm-kmod-2.6.30, and kvm-91.
> 
> Making all KVM_CAPs mandatory only works if we carry the headers with qemu.

If we continue to carry our own headers, the #ifdefs are pointless. If
we don't, the configure checks should issue an overview on all the
features that will be missing and give a hint how to resolve this
(kvm-kmod...).

> 
>> Whatever the strategy will be, it should be one with the clear goal to
>> converge over the same approach with upstream.
>>   
> 
> Definitely.  In this case I'm still not sure what we want, though.
> 

Maybe a good topic for next Tuesday.

Jan


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 257 bytes --]