Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1454093
| From | Radim Krčmář <rkrcmar@redhat.com> |
|---|---|
| Newsgroups | linux.kernel |
| Subject | Re: [PATCH v3 04/14] KVM: x86: dynamic kvm_apic_map |
| Date | 2016-08-02 14:30 +0200 |
| Message-ID | <s1GZB-4ne-91@gated-at.bofh.it> (permalink) |
| References | <rUcjT-1np-3@gated-at.bofh.it> <rUcjU-1np-11@gated-at.bofh.it> <s1GZB-4ne-93@gated-at.bofh.it> |
| Organization | linux.* mail to news gateway |
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.
Back to linux.kernel | Previous | Next — Next in thread | Find similar | Unroll thread
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
csiph-web