qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH 07/12] kvm: Drop KVM_CAP build dependencies


From: Alexander Graf
Subject: Re: [Qemu-devel] [PATCH 07/12] kvm: Drop KVM_CAP build dependencies
Date: Tue, 14 Jun 2011 13:25:32 +0200

On 14.06.2011, at 13:19, Jan Kiszka wrote:

> On 2011-06-14 13:17, Alexander Graf wrote:
>> 
>> On 14.06.2011, at 13:07, Jan Kiszka wrote:
>> 
>>> On 2011-06-14 13:05, Alexander Graf wrote:
>>>> 
>>>> On 08.06.2011, at 16:11, Jan Kiszka wrote:
>>>> 
>>>>> No longer needed with accompanied kernel headers. We are only left with
>>>>> build dependencies that are controlled by kvm arch headers.
>>>> 
>>>> This should completely rule out all CAPs right? IIRC, all CAPs are defined 
>>>> in generic code, so we don't get number overlaps.
>>> 
>>> "We are only left with build dependencies that are controlled by kvm
>>> arch headers." E.g. KVM_CAP_VCPU_EVENTS.
>>> 
>>>> 
>>>>> 
>>>>> CC: Alexander Graf <address@hidden>
>>>>> Signed-off-by: Jan Kiszka <address@hidden>
>>>>> ---
>>>>> kvm-all.c |    8 --------
>>>>> 1 files changed, 0 insertions(+), 8 deletions(-)
>>>>> 
>>>>> diff --git a/kvm-all.c b/kvm-all.c
>>>>> index 4a9910a..cbc2532 100644
>>>>> --- a/kvm-all.c
>>>>> +++ b/kvm-all.c
>>>>> @@ -757,21 +757,17 @@ int kvm_init(void)
>>>>>   s->coalesced_mmio = kvm_check_extension(s, KVM_CAP_COALESCED_MMIO);
>>>>> 
>>>>>   s->broken_set_mem_region = 1;
>>>>> -#ifdef KVM_CAP_JOIN_MEMORY_REGIONS_WORKS
>>>>>   ret = kvm_check_extension(s, KVM_CAP_JOIN_MEMORY_REGIONS_WORKS);
>>>>>   if (ret > 0) {
>>>>>       s->broken_set_mem_region = 0;
>>>>>   }
>>>>> -#endif
>>>>> 
>>>>> #ifdef KVM_CAP_VCPU_EVENTS
>>>> 
>>>> ... which leaves the question why this one is still here :).
>>> 
>>> See above (does PPC support it?).
>> 
>> Well, regardless of support, the #ifdef shouldn't be required, right?
>> 
>> include/linux/kvm.h:518:#define KVM_CAP_VCPU_EVENTS 41
>> 
>> ... as long as there's a runtime check :)
> 
> Are all types and dependent constants available? Maybe it is the case
> here, but you cannot generally assume this if a CAP is per-arch.

Ah, I see what you mean. Maybe it'd be easier to use __KVM_HAVE_VCPU_EVENTS 
instead of the implicitly defined CAP? But then again, once all the version CAP 
#ifdefs are gone, the only ones left are the ones for arch features, so I guess 
your approach is valid :)


Alex




reply via email to

[Prev in Thread] Current Thread [Next in Thread]