From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1030827AbcGKOO5 (ORCPT ); Mon, 11 Jul 2016 10:14:57 -0400 Received: from mx1.redhat.com ([209.132.183.28]:40118 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1030787AbcGKOO4 (ORCPT ); Mon, 11 Jul 2016 10:14:56 -0400 Subject: Re: [PATCH v2 04/13] KVM: x86: dynamic kvm_apic_map To: =?UTF-8?B?UmFkaW0gS3LEjW3DocWZ?= , Yang Zhang 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> Cc: linux-kernel@vger.kernel.org, kvm@vger.kernel.org, "Lan, Tianyu" , Igor Mammedov , Jan Kiszka , Peter Xu From: Paolo Bonzini Message-ID: <6dda9370-e538-2c7c-e95e-b6a6f1518bbf@redhat.com> Date: Mon, 11 Jul 2016 16:14:46 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.1.1 MIME-Version: 1.0 In-Reply-To: <20160711134837.GD21976@potion> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.26]); Mon, 11 Jul 2016 14:14:51 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 11/07/2016 15:48, Radim Krčmář 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 mode. > > (I guess the fewest LOC is to look at vcpu->vcpu_id, which is equal to > 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_id in kvm_apic_id? >> Or we can just simply put the assignment of apic_base to the end. > > Yes, this would work, I'd also remove recalculates from > kvm_apic_set_*apic_id() and add a compiler barrier with comment for good > 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 we > 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 physical > 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 with > with respect to the APIC that has changed, instead of being completely > recomputed, so maybe the time is now. :) >