From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751903AbcGGKPy (ORCPT ); Thu, 7 Jul 2016 06:15:54 -0400 Received: from userp1040.oracle.com ([156.151.31.81]:47447 "EHLO userp1040.oracle.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751418AbcGGKPw (ORCPT ); Thu, 7 Jul 2016 06:15:52 -0400 Subject: Re: [Xen-devel] [PATCH linux 2/8] xen: introduce xen_vcpu_id mapping To: Jan Beulich , Konrad Rzeszutek Wilk 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> <689743e6-0b0e-9935-58e1-2dfa257c7bf8@citrix.com> <87oa6kupko.fsf@vitty.brq.redhat.com> <87k2h8ufw0.fsf@vitty.brq.redhat.com> <5040c916-279f-c350-383a-583ec1700686@citrix.com> <5774FE1302000078000F9FED@prv-mh.provo.novell.com> <20160705153412.GD6428@char.us.oracle.com> <577BF1FC02000078000FB51A@prv-mh.provo.novell.com> Cc: Juergen Gross , Stefano Stabellini , Andrew Cooper , x86@kernel.org, linux-kernel@vger.kernel.org, Vitaly Kuznetsov , Ingo Molnar , David Vrabel , "H. Peter Anvin" , xen-devel@lists.xenproject.org, Thomas Gleixner , Boris Ostrovsky From: Joao Martins Message-ID: <577E2BDB.7070902@oracle.com> Date: Thu, 7 Jul 2016 11:15:55 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Icedove/38.7.0 MIME-Version: 1.0 In-Reply-To: <577BF1FC02000078000FB51A@prv-mh.provo.novell.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Source-IP: aserv0021.oracle.com [141.146.126.233] Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 07/05/2016 04:44 PM, Jan Beulich wrote: >>>> On 05.07.16 at 17:34, wrote: >> On Thu, Jun 30, 2016 at 03:10:11AM -0600, Jan Beulich wrote: >>>>>> On 29.06.16 at 18:27, wrote: >>>> On 29/06/16 17:19, Vitaly Kuznetsov wrote: >>>>> To explain better what I'm trying to suggest here please take a look at >>>>> the attached patch. If we can guarantee long term that ACPI id always >>>>> equals to Xen's idea of vCPU id this is probably the easiest way. >>>>> >>>>> -- Vitaly >>>> >>>> The code in hvmloader which sets up the MADT does: >>>> >>>> for ( i = 0; i < hvm_info->nr_vcpus; i++ ) >>>> { >>>> memset(lapic, 0, sizeof(*lapic)); >>>> lapic->type = ACPI_PROCESSOR_LOCAL_APIC; >>>> lapic->length = sizeof(*lapic); >>>> /* Processor ID must match processor-object IDs in the DSDT. */ >>>> lapic->acpi_processor_id = i; >>>> lapic->apic_id = LAPIC_ID(i); >>>> lapic->flags = (test_bit(i, hvm_info->vcpu_online) >>>> ? ACPI_LOCAL_APIC_ENABLED : 0); >>>> lapic++; >>>> } >>>> >>>> So relying on the acpi_processor_id does look to be reliable. That code >>>> hasn't changed since 2007, and that was only a bugfix. I would go so >>>> far as to say it is reasonable for us to guarantee this in the guest ABI. >>> >>> In fact - is there any other way a guest could learn the vCPU IDs >>> of its CPUs in a reliable way? I don't think so, and hence this de >>> facto already is part of the ABI; we should of course spell it out >>> somewhere. >> >> CCing Joao. >> >> Joao worked (and I think he posted an RFC patchset?) where this is changed so >> that the true hardware topology (core, thread, etc) is exposed. This is obviously >> for cases where you want pinning. >> >> I would hesistate to spell this out as an ABI.. > > Are you perhaps mixing up ACPI and APIC IDs? Here talk is of the > former, while Joao's patch set was about the latter iirc. > Correct, my patch series indeed changed APIC IDs. I guess making acpi_processor_id to get vcpu_id reliably stated as guest ABI, is safe wrt to future arrangements to apic_ids. Joao