From mboxrd@z Thu Jan 1 00:00:00 1970 From: Paolo Bonzini Subject: Re: [PATCH v2 04/13] KVM: x86: dynamic kvm_apic_map Date: Mon, 11 Jul 2016 16:14:46 +0200 Message-ID: <6dda9370-e538-2c7c-e95e-b6a6f1518bbf@redhat.com> References: <20160707171550.14675-1-rkrcmar@redhat.com> <20160707171550.14675-5-rkrcmar@redhat.com> <963b542a-1111-db83-8338-c32d44f98874@gmail.com> <3a5d86b6-9f1a-a6cf-8af4-ef6bf3936996@gmail.com> <20160711134837.GD21976@potion> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: QUOTED-PRINTABLE Cc: linux-kernel@vger.kernel.org, kvm@vger.kernel.org, "Lan, Tianyu" , Igor Mammedov , Jan Kiszka , Peter Xu To: =?UTF-8?B?UmFkaW0gS3LEjW3DocWZ?= , Yang Zhang Return-path: In-Reply-To: <20160711134837.GD21976@potion> Sender: linux-kernel-owner@vger.kernel.org List-Id: kvm.vger.kernel.org On 11/07/2016 15:48, Radim Kr=C4=8Dm=C3=A1=C5=99 wrote: >>> I guess the easiest solution is to replace kvm_apic_id with a field= in >>> struct kvm_lapic, which is already shifted right by 24 in xAPIC mod= e. >=20 > (I guess the fewest LOC is to look at vcpu->vcpu_id, which is equal t= o > x2apic id. xapic id cannot be greater than 255 and all of those are > covered by the initial value of max_id.) Yes, this would work too. Or even better perhaps, look at vcpu->vcpu_i= d in kvm_apic_id? >> Or we can just simply put the assignment of apic_base to the end. >=20 > Yes, this would work, I'd also remove recalculates from > kvm_apic_set_*apic_id() and add a compiler barrier with comment for g= ood > measure, even though set_virtual_x2apic_mode() serves as one. Why a compiler barrier? > (What makes a bit wary is that it doesn't avoid the same problem if w= e > changed KVM to reset apic id to xapic id first when disabling apic.) Yes, this is why I prefer it fixed once and for all in kvm_apic_id... > Races in recalculation and APIC ID changes also lead to invalid physi= cal > maps, which haven't been taken care of properly ... Hmm, true, but can be fixed separately. Probably the mutex should be renamed so that it can be taken outside recalculate_apic_map... Paolo > Having apic id stored in big endian, or "0-7,8-31" format, would be > safest. I wanted to change the apic map to do incremental updates wi= th > with respect to the APIC that has changed, instead of being completel= y > recomputed, so maybe the time is now. :) >=20