From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755353AbcGEPfq (ORCPT ); Tue, 5 Jul 2016 11:35:46 -0400 Received: from aserp1040.oracle.com ([141.146.126.69]:16579 "EHLO aserp1040.oracle.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752524AbcGEPfo (ORCPT ); Tue, 5 Jul 2016 11:35:44 -0400 Date: Tue, 5 Jul 2016 11:34:12 -0400 From: Konrad Rzeszutek Wilk To: Jan Beulich , Joao Martins Cc: Andrew Cooper , Vitaly Kuznetsov , Juergen Gross , Stefano Stabellini , x86@kernel.org, linux-kernel@vger.kernel.org, Ingo Molnar , David Vrabel , "H. Peter Anvin" , xen-devel@lists.xenproject.org, Boris Ostrovsky , Thomas Gleixner Subject: Re: [Xen-devel] [PATCH linux 2/8] xen: introduce xen_vcpu_id mapping Message-ID: <20160705153412.GD6428@char.us.oracle.com> 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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5774FE1302000078000F9FED@prv-mh.provo.novell.com> User-Agent: Mutt/1.5.24 (2015-08-30) 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 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.. P.S. Which reminds me, Joao, you OK posting the patchset? > > Jan > > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xen.org > http://lists.xen.org/xen-devel