linux-kernel - Re: [Xen-devel] [PATCH linux 2/8] xen: introduce xen_vcpu

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <577BF1FC02000078000FB51A@prv-mh.provo.novell.com>
Date:	Tue, 05 Jul 2016 09:44:28 -0600
From:	"Jan Beulich" <JBeulich@...e.com>
To:	"Konrad Rzeszutek Wilk" <konrad.wilk@...cle.com>
Cc:	"Andrew Cooper" <andrew.cooper3@...rix.com>,
	"David Vrabel" <david.vrabel@...rix.com>,
	"Stefano Stabellini" <sstabellini@...nel.org>, <x86@...nel.org>,
	"Thomas Gleixner" <tglx@...utronix.de>,
	<xen-devel@...ts.xenproject.org>,
	"Boris Ostrovsky" <boris.ostrovsky@...cle.com>,
	"Joao Martins" <joao.m.martins@...cle.com>,
	"Ingo Molnar" <mingo@...hat.com>,
	"Vitaly Kuznetsov" <vkuznets@...hat.com>,
	"Juergen Gross" <JGross@...e.com>, <linux-kernel@...r.kernel.org>,
	"H. Peter Anvin" <hpa@...or.com>
Subject: Re: [Xen-devel] [PATCH linux 2/8] xen: introduce xen_vcpu_id
 mapping

>>> On 05.07.16 at 17:34, <konrad.wilk@...cle.com> wrote:
> On Thu, Jun 30, 2016 at 03:10:11AM -0600, Jan Beulich wrote:
>> >>> On 29.06.16 at 18:27, <andrew.cooper3@...rix.com> 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.

Jan