WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

Re: [Xen-devel] [PATCH][retry 2][2/2] new platform hypervisor call to ge

To: Jan Beulich <jbeulich@xxxxxxxxxx>, Mark Langsdorf <mark.langsdorf@xxxxxxx>
Subject: Re: [Xen-devel] [PATCH][retry 2][2/2] new platform hypervisor call to get APICIDs
From: Keir Fraser <keir.fraser@xxxxxxxxxxxxx>
Date: Tue, 04 Mar 2008 11:43:31 +0000
Cc: xen-devel@xxxxxxxxxxxxxxxxxxx, Chris Lalancette <clalance@xxxxxxxxxx>
Delivery-date: Tue, 04 Mar 2008 03:44:53 -0800
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <C3F2C77B.1D64D%keir.fraser@xxxxxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: Ach92oxJyw4AQOnNEdyzcwAX8io7RQAEmvpY
Thread-topic: [Xen-devel] [PATCH][retry 2][2/2] new platform hypervisor call to get APICIDs
User-agent: Microsoft-Entourage/11.3.6.070618
On 4/3/08 09:31, "Keir Fraser" <keir.fraser@xxxxxxxxxxxxx> wrote:

>> Finally, I'm worried about the way you handle dom0_vcpus_pinned:
>> By its name, I would assume that if I (later, for whatever reason) use
>> it elsewhere, I can be certain it means what it says. However, at
>> present, the hypercall succeeding does not imply that VCPUs are
>> indeed pinned. Further, under !is_initial_xen_domain() you shouldn't
>> set it, nor should you have a reason to even attempt the hypercall.
> 
> I'm happy to clean up the dom0_vcpus_pinned side of this patch myself.
> Anyway, if we make it a singleton-apicid vcpu_op, which fails on anything
> other than a pinned dom0, I think we're good. I like the idea of simply
> plucking the APICID from CPUID, but it does munge the code and I'm a bit
> worried that we couldn't get the APICID until rather later than native Linux
> (probably after the AP has booted but before it 'calls in').

Also there is no particular reason not to have this vcpu_op return the
acpiid as well. Call it something like VCPUOP_phys_id, returns an
arch-specific uint64_t phys_id. On x86 we could have 8-bit apicid plus 8-bit
acpiid packed into that uint64_t, with the other 48 bits being MBZ for
future expansion (e.g., x2apic extra id bits should we ever care). Either id
can be 0xff indicating 'not available'.

 -- Keir



_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel