Re: [PATCH v2 2/4] KVM: x86: replace kvm_apic_id with kvm_{x,x2}apic_id

Radim Krčmář
2016-12-14T17:16:41Z

2016-12-14 17:59+0100, Paolo Bonzini:
> On 14/12/2016 17:15, David Hildenbrand wrote:
>>
>>> kvm_for_each_vcpu(i, vcpu, kvm)
>>> if (kvm_apic_present(vcpu))
>>> - max_id = max(max_id, kvm_apic_id(vcpu->arch.apic));
>>> + max_id = max(max_id, kvm_x2apic_id(vcpu->arch.apic));
>>>
>>> new = kvm_kvzalloc(sizeof(struct kvm_apic_map) +
>>> sizeof(struct kvm_lapic *) * ((u64)max_id + 1));
>>> @@ -179,16 +189,23 @@ static void recalculate_apic_map(struct kvm *kvm)
>>> struct kvm_lapic *apic = vcpu->arch.apic;
>>> struct kvm_lapic **cluster;
>>> u16 mask;
>>> - u32 ldr, aid;
>>> + u32 ldr;
>>> + u8 xapic_id;
>>> + u32 x2apic_id;
>>>
>>> if (!kvm_apic_present(vcpu))
>>> continue;
>>>
>>> - aid = kvm_apic_id(apic);
>>
>> think I'd even prefer here a simple
>>
>> aid = kvm_xapic_id(apic);
>> if (apic_x2apic_mode(apic))
>> aid = kvm_x2apic_id(apic);
>>
>> that would keep changes minimal and I don't really see any benefit in
>> the code when splitting handling up.
>>
>> Patch 4 then simply can fixup setting code
>>
>> if (aid <= new->max_apic_id && !new->phys_map[aid])
>> new->phys_map[aid] = apic;
>>
>> (if I am not missing some important corner case here)
>
> Radim, what do you think? I wanted to get these in before Christmas,
> but it's your call.

There was a reason why it was so ugly ... it's not a hack for nothing.

I can hope to make the patches/code more understandable, but the
function shouldn't change, unless we want to take a different approach.