From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752240AbcGANzA (ORCPT ); Fri, 1 Jul 2016 09:55:00 -0400 Received: from prv-mh.provo.novell.com ([137.65.248.74]:47162 "EHLO prv-mh.provo.novell.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750702AbcGANy6 convert rfc822-to-8bit (ORCPT ); Fri, 1 Jul 2016 09:54:58 -0400 Message-Id: <57768D6202000078000FA6B3@prv-mh.provo.novell.com> X-Mailer: Novell GroupWise Internet Agent 14.2.0 Date: Fri, 01 Jul 2016 07:33:54 -0600 From: "Jan Beulich" To: "Vitaly Kuznetsov" Cc: "Andrew Cooper" , "David Vrabel" , "Stefano Stabellini" , , "Thomas Gleixner" , , "Boris Ostrovsky" , "Ingo Molnar" , "Juergen Gross" , , "H. Peter Anvin" Subject: Re: [Xen-devel] [PATCH linux 2/8] xen: introduce xen_vcpu_id mapping 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><5774FE1302000078000F9FED@prv-mh.provo.novell.com> (Jan Beulich's message of "Thu, 30 Jun 2016 03:10:11 -0600") <87y45lsgtd.fsf@vitty.brq.redhat.com> In-Reply-To: <87y45lsgtd.fsf@vitty.brq.redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 8BIT Content-Disposition: inline Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org >>> On 01.07.16 at 14:06, wrote: > "Jan Beulich" writes: > >>>>> 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. > > I'm unsure about the right place in the hypervisor tree to put this > information to. At the very least users of VCPUOP_* and EVTCHNOP_* > hypervcalls need to know this so xen/include/public/{event_channel.h, > vcpu.h} are the candidates. Or is there a better place? I'd probably put this in public/hvm/hvm_info_table.h or public/hvm/hvm_vcpu.h; the two headers you name shouldn't be cluttered with information like this not pertaining to all guests. Jan