Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1454093 > unrolled thread

Re: [PATCH v3 04/14] KVM: x86: dynamic kvm_apic_map

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: [PATCH v3 04/14] KVM: x86: dynamic kvm_apic_map Radim Krčmář <rkrcmar@redhat.com> - 2016-08-02 14:30 +0200
    Re: [PATCH v3 04/14] KVM: x86: dynamic kvm_apic_map Wanpeng Li <kernellwp@gmail.com> - 2016-08-02 15:30 +0200

#1454093 — Re: [PATCH v3 04/14] KVM: x86: dynamic kvm_apic_map

2016-08-02 19:39+0800, Wanpeng Li:
> 2016-07-13 4:09 GMT+08:00 Radim Krčmář <rkrcmar@redhat.com>:
> [...]
>> diff --git a/arch/x86/kvm/lapic.c b/arch/x86/kvm/lapic.c
>> @@ -152,14 +152,22 @@ static void recalculate_apic_map(struct kvm *kvm)
>>         struct kvm_apic_map *new, *old = NULL;
>>         struct kvm_vcpu *vcpu;
>>         int i;
>> -
>> -       new = kzalloc(sizeof(struct kvm_apic_map), GFP_KERNEL);
>> +       u32 max_id = 255;
> 
> If this should be max_id = KVM_MAX_VCPU_ID? I have a patch on hand to
> fix it, but I didn't know whether it is your desired behavior or not.

No, we could just have static array then.  KVM_MAX_VCPU_ID is expected
to be raised to INT_MAX and eventually UINT_MAX, so it would not be
practical.  The dynamic array is there to avoid wasting space in the
common case, where VMs have only low APIC IDs.

Inintial patches had 255 to minimize a chance of regressions as the
static array was that big, but starting with max_id = 0 is our goal and
should be ok even without other changes.

[toc] | [next] | [standalone]

#1454341

2016-08-02 20:22 GMT+08:00 Radim Krčmář <rkrcmar@redhat.com>:
> 2016-08-02 19:39+0800, Wanpeng Li:
>> 2016-07-13 4:09 GMT+08:00 Radim Krčmář <rkrcmar@redhat.com>:
>> [...]
>>> diff --git a/arch/x86/kvm/lapic.c b/arch/x86/kvm/lapic.c
>>> @@ -152,14 +152,22 @@ static void recalculate_apic_map(struct kvm *kvm)
>>>         struct kvm_apic_map *new, *old = NULL;
>>>         struct kvm_vcpu *vcpu;
>>>         int i;
>>> -
>>> -       new = kzalloc(sizeof(struct kvm_apic_map), GFP_KERNEL);
>>> +       u32 max_id = 255;
>>
>> If this should be max_id = KVM_MAX_VCPU_ID? I have a patch on hand to
>> fix it, but I didn't know whether it is your desired behavior or not.
>
> No, we could just have static array then.  KVM_MAX_VCPU_ID is expected
> to be raised to INT_MAX and eventually UINT_MAX, so it would not be
> practical.  The dynamic array is there to avoid wasting space in the
> common case, where VMs have only low APIC IDs.
>
> Inintial patches had 255 to minimize a chance of regressions as the
> static array was that big, but starting with max_id = 0 is our goal and
> should be ok even without other changes.

I see, thanks. :)

Regards,
Wanpeng Li

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web