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

[Keir Fraser <keir.fraser@xxxxxxxxxxxxx>]

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