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

[Paul Durrant <Paul.Durrant@xxxxxxxxxx>]

> -----Original Message-----
> From: Matt Wilson [mailto:mswilson@xxxxxxxxx] On Behalf Of Matt Wilson
> Sent: 10 December 2014 17:27
> To: Paul Durrant
> Cc: win-pv-devel@xxxxxxxxxxxxxxxxxxxx
> Subject: 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?
> 

Do you fix the ACPI tables up in EC2? I assume Windows uses ACPI to number its 
CPUs so we could trust that value if we know it to match the vcpu id.

  Paul

> --msw

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