From: Peter Xu <peterx@redhat.com>
To: "Radim Krčmář" <rkrcmar@redhat.com>
Cc: kvm@vger.kernel.org, Paolo Bonzini <pbonzini@redhat.com>,
"Lan, Tianyu" <tianyu.lan@intel.com>,
Igor Mammedov <imammedo@redhat.com>,
Jan Kiszka <jan.kiszka@web.de>
Subject: Re: [PATCH 2/9] KVM: x86: dynamic kvm_apic_map
Date: Mon, 23 May 2016 16:04:01 +0800 [thread overview]
Message-ID: <20160523080401.GC8247@pxdev.xzpeter.org> (raw)
In-Reply-To: <1462568045-31085-3-git-send-email-rkrcmar@redhat.com>
Hi, Radim,
Got several questions inline.
On Fri, May 06, 2016 at 10:53:58PM +0200, Radim Krčmář wrote:
> x2APIC supports up to 2^32-1 LAPICs, but most guest in coming years will
> have slighly less VCPUs. Dynamic size saves memory at the cost of
> turning one constant into a variable.
From the manual, I see x2apic only support 2^20-16 processors, not
2^32-1. Which one is correct?
From below codes [1], I still see 2^20-16, since we are using high
16 bits of dest ID as cluster ID (0-0xfffe, while I guess 0xffff
should be reserved), and lower 16 bits as processor/lapic mask.
[...]
> +static inline bool kvm_apic_map_get_logical_dest(struct kvm_apic_map *map,
> + u32 dest_id, struct kvm_lapic ***cluster, u16 *mask) {
> + switch (map->mode) {
> + case KVM_APIC_MODE_X2APIC: {
> + u32 offset = (dest_id >> 16) * 16;
> + // XXX: phys_map must be allocated as multiples of 16
> + if (offset < map->size) {
> + *cluster = &map->phys_map[offset];
> + *mask = dest_id & 0xffff;
[1]
[...]
> static void recalculate_apic_map(struct kvm *kvm)
> @@ -156,17 +162,28 @@ 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 size = 255;
>
> mutex_lock(&kvm->arch.apic_map_lock);
>
> + kvm_for_each_vcpu(i, vcpu, kvm)
> + if (kvm_apic_present(vcpu))
> + size = max(size, kvm_apic_id(vcpu->arch.apic));
> +
> + size++;
> + size += (16 - size) & 16;
Is this same as:
size = round_up(size, 16);
?
Thanks,
-- peterx
next prev parent reply other threads:[~2016-05-23 8:04 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-05-06 20:53 [RFC 0/9] KVM: x86: break the xAPIC barrier Radim Krčmář
2016-05-06 20:53 ` [PATCH 1/9] KVM: x86: add kvm_apic_map_get_dest_lapic Radim Krčmář
2016-05-19 6:36 ` Peter Xu
2016-05-25 16:02 ` Radim Krčmář
2016-05-26 11:58 ` Peter Xu
2016-05-06 20:53 ` [PATCH 2/9] KVM: x86: dynamic kvm_apic_map Radim Krčmář
2016-05-23 8:04 ` Peter Xu [this message]
2016-05-25 16:15 ` Radim Krčmář
2016-05-30 5:24 ` Peter Xu
2016-05-06 20:53 ` [PATCH 3/9] KVM: x86: use u16 for logical VCPU mask in lapic Radim Krčmář
2016-05-06 20:54 ` [PATCH 4/9] KVM: x86: use generic function for MSI parsing Radim Krčmář
2016-05-06 20:54 ` [PATCH 5/9] KVM: support x2APIC ID in userspace routes Radim Krčmář
2016-05-06 20:54 ` [PATCH 6/9] KVM: x86: directly call recalculate_apic_map on lapic restore Radim Krčmář
2016-05-23 8:30 ` Peter Xu
2016-05-06 20:54 ` [PATCH 7/9] KVM: x86: use proper format of APIC ID register Radim Krčmář
2016-05-17 15:34 ` Paolo Bonzini
2016-05-25 16:30 ` Radim Krčmář
2016-05-06 20:54 ` [PATCH 8/9] KVM: x86: reset lapic base in kvm_lapic_reset Radim Krčmář
2016-05-06 20:54 ` [PATCH 9/9] KVM: bump MAX_VCPUS Radim Krčmář
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20160523080401.GC8247@pxdev.xzpeter.org \
--to=peterx@redhat.com \
--cc=imammedo@redhat.com \
--cc=jan.kiszka@web.de \
--cc=kvm@vger.kernel.org \
--cc=pbonzini@redhat.com \
--cc=rkrcmar@redhat.com \
--cc=tianyu.lan@intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.