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 <agraf@xxxxxxx>
>>>>> Signed-off-by: Jan Kiszka <jan.kiszka@xxxxxxxxxxx>
>>>>> ---
>>>>> 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
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
