[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: [Xen-devel] dom0 and apicid not equal to cpuid

  • To: "Keir Fraser" <Keir.Fraser@xxxxxxxxxxxx>, xen-devel@xxxxxxxxxxxxxxxxxxx
  • From: "Langsdorf, Mark" <mark.langsdorf@xxxxxxx>
  • Date: Tue, 12 Feb 2008 09:33:12 -0600
  • Delivery-date: Tue, 12 Feb 2008 07:34:00 -0800
  • List-id: Xen developer discussion <xen-devel.lists.xensource.com>
  • Thread-index: Achqll4p+tddFVOYTAK5v3h066MrkQAAfHYmAJlI5yAAGSyR0wAKh6fQ
  • Thread-topic: [Xen-devel] dom0 and apicid not equal to cpuid

> > It appears that the call to GET_APIC_ID() in
> > mp_register_lapic_address() isn't legal for dom0, but the failure
> > to make that call results in an incorrect cpu_to_apicid[] table
> > and that means the acpiid_to_apicid[] table is also wrong.
> The code in processor_core.c ultimately wants to convert 
> acpiid to cpuid. I think we're going to be in a confusing
> mess if we set up the acpiid-apicid-cpuid relationships for
> anything other than a dom0_vcpu_pin'ed system.

Agreed.  That's all I really need it for anyway.

> So perhaps we should expose that configuration option 
> to dom0 (so it can tell whether it is pinned or not)... 

Good idea.

> In the non-pinned case perhaps we should initialise all those
> arrays to -1 for sanity's sake.

If this had been done initially, I'd think it was a good idea,
but I'm worried about introducing that kind of change now.

> Do you think you could do the Linux side of this in a reasonably clean
> manner? You could provide a Linux kernel command-line option 
> to specify pinned/not-pinned for now if you like, and I would do the 
> proper plumbing through from Xen.

Sure, I'll try to get something out soon.

-Mark Langsdorf
Operating System Research Center

Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.