From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752201AbcGAMIW (ORCPT ); Fri, 1 Jul 2016 08:08:22 -0400 Received: from mx1.redhat.com ([209.132.183.28]:42898 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750715AbcGAMIU (ORCPT ); Fri, 1 Jul 2016 08:08:20 -0400 From: Vitaly Kuznetsov To: "Jan Beulich" 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> Date: Fri, 01 Jul 2016 14:06:54 +0200 In-Reply-To: <5774FE1302000078000F9FED@prv-mh.provo.novell.com> (Jan Beulich's message of "Thu, 30 Jun 2016 03:10:11 -0600") Message-ID: <87y45lsgtd.fsf@vitty.brq.redhat.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.28]); Fri, 01 Jul 2016 12:06:59 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org "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? -- Vitaly