From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752299AbcF2MaV (ORCPT ); Wed, 29 Jun 2016 08:30:21 -0400 Received: from smtp02.citrix.com ([66.165.176.63]:25786 "EHLO SMTP02.CITRIX.COM" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751767AbcF2MaU (ORCPT ); Wed, 29 Jun 2016 08:30:20 -0400 X-IronPort-AV: E=Sophos;i="5.26,546,1459814400"; d="scan'208";a="370343249" Subject: Re: [Xen-devel] [PATCH linux 2/8] xen: introduce xen_vcpu_id mapping To: Vitaly Kuznetsov References: <1467132449-1030-1-git-send-email-vkuznets@redhat.com> <1467132449-1030-3-git-send-email-vkuznets@redhat.com> <87shvwur5p.fsf@vitty.brq.redhat.com> CC: , Juergen Gross , "Stefano Stabellini" , , , Julien Grall , "Ingo Molnar" , David Vrabel , "H. Peter Anvin" , Boris Ostrovsky , "Thomas Gleixner" , Jan Beulich From: Andrew Cooper Message-ID: <689743e6-0b0e-9935-58e1-2dfa257c7bf8@citrix.com> Date: Wed, 29 Jun 2016 13:30:13 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Icedove/45.1.0 MIME-Version: 1.0 In-Reply-To: <87shvwur5p.fsf@vitty.brq.redhat.com> Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: 7bit X-DLP: MIA1 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 29/06/16 13:16, Vitaly Kuznetsov wrote: > Andrew Cooper writes: > >> On 28/06/16 17:47, Vitaly Kuznetsov wrote: >>> @@ -1808,6 +1822,8 @@ static int xen_hvm_cpu_notify(struct notifier_block *self, unsigned long action, >>> int cpu = (long)hcpu; >>> switch (action) { >>> case CPU_UP_PREPARE: >>> + /* vLAPIC_ID == Xen's vCPU_ID * 2 for HVM guests */ >>> + per_cpu(xen_vcpu_id, cpu) = cpu_physical_id(cpu) / 2; >> Please do not assume or propagate this brokenness. It is incorrect in >> the general case, and I will be fixing in the hypervisor in due course. >> >> Always read the APIC_ID from the LAPIC, per regular hardware. > (I'm probbaly missing something important - please bear with me) > > The problem here is that I need to get _other_ CPU's id before any code > is executed on that CPU (or, at least, this is the current state of > affairs if you look at xen_hvm_cpu_up()) so I can't use CPUID/do MSR > reads/... The only option I see here is to rely on ACPI (MADT) data > which is stored in x86_cpu_to_apicid (and that's what cpu_physical_id() > gives us). MADT also has processor id which connects it to DSDT but I'm > not sure Linux keeps this data. But this is something fixable I guess. Hmm yes - that is a tricky issue. It is not safe or correct to assume that xen_vcpu_id is APICID / 2. This is currently the case for most modern versions of Xen, but isn't the case for older versions, and won't be the case in the future when I (or someone else) fixes topology representation for guests. For this to work, we need one or more of: 1) to provide the guest a full mapping from APIC_ID to vcpu id at boot time. 2) add a new interface where the guest can explicitly query "what is the vcpu id for the entity with this APIC_ID". 3) Allow HVM guests to identify a vcpu in a hypercall by APIC_ID. 3 is the cleaner approach, but given that vcpu ids have already leaked into an HVM domains idea of the world, 1 or 2 is probably a better ladder to dig us out of this hole. ~Andrew.