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

[Matt Wilson <msw@xxxxxxxxx>]

On Wed, Dec 10, 2014 at 05:38:04PM +0000, Paul Durrant wrote:
> > -----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:

[...]

> > >
> > > 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.

Yes, the MADT LAPIC structs have the correct values. The
acpi_processor_id field will be the index of the vCPU. The MADT LAPIC
apic_id field will match the default APIC IDs returned by CPUID input
EAX=1h output EBX[24..31], and input EAX=2b output EDX.

The legacy mptable is also indexed on vCPU ID, and contains the
correct default APIC ID for each processor.

--msw

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