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

Re: [win-pv-devel] [PATCH 04/10] Separate checking upcall_pending in shared info from EvtchnPoll



On Wed, Dec 10, 2014 at 02:10:49PM +0000, Paul Durrant wrote:
> > -----Original Message-----
> > From: Matt Wilson [mailto:mswilson@xxxxxxxxx] On Behalf Of Matt Wilson
> > Sent: 10 December 2014 06:16
> > To: Paul Durrant
> > Cc: win-pv-devel@xxxxxxxxxxxxxxxxxxxx
> > Subject: Re: [PATCH 04/10] Separate checking upcall_pending in shared info
> > from EvtchnPoll
> > 
> > On Thu, Nov 06, 2014 at 02:24:15PM +0000, Paul Durrant wrote:

[...]

> > > +    return Cpu->ApicID / 2;
> > 
> > Nack. This will break on EC2 instances that expose CPU topology by
> > setting the initial APIC ID appropriately (i.e., not according to the
> > *2 formula.
> 
> That's a shame. The code really doesn't have much option but to use
> this mechanism as Xen provides no explicit way for an HVM guest to
> get vcpu ids until my patch "x86/hvm: Extend HVM cpuid leaf with
> vcpu id" goes in and use of the FIFO ABI requires knowledge of vcpu
> id.

Could you use the ACPI processor object ID number? Or use the initial
APIC ID to ACPI processor ID mapping in the LAPIC part of MADT?

--msw

_______________________________________________
win-pv-devel mailing list
win-pv-devel@xxxxxxxxxxxxxxxxxxxx
http://lists.xenproject.org/cgi-bin/mailman/listinfo/win-pv-devel


 


Rackspace

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