[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


  • To: Matt Wilson <msw@xxxxxxxxx>
  • From: Paul Durrant <Paul.Durrant@xxxxxxxxxx>
  • Date: Fri, 12 Dec 2014 09:45:07 +0000
  • Accept-language: en-GB, en-US
  • Cc: "win-pv-devel@xxxxxxxxxxxxxxxxxxxx" <win-pv-devel@xxxxxxxxxxxxxxxxxxxx>
  • Delivery-date: Fri, 12 Dec 2014 09:45:13 +0000
  • List-id: Developer list for the Windows PV Drivers subproject <win-pv-devel.lists.xenproject.org>
  • Thread-index: AQHP+c1yoch+bKh86UuUQIBjLuu7fpyIfUcAgACUEVCAACc2AIAAEoKggAAAoICAAe3JAIAAsrXg
  • Thread-topic: [win-pv-devel] [PATCH 04/10] Separate checking upcall_pending in shared info from EvtchnPoll

> -----Original Message-----
> From: win-pv-devel-bounces@xxxxxxxxxxxxxxxxxxxx [mailto:win-pv-devel-
> bounces@xxxxxxxxxxxxxxxxxxxx] On Behalf Of Matt Wilson
> Sent: 12 December 2014 00:03
> 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 10:35:11AM -0800, Matt Wilson wrote:
> > 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.
> 
> What do you think about using the Viridian MSR for Virtual Processor
> Index as I mentioned on xen-devel?
> 
>   http://lists.xenproject.org/archives/html/xen-devel/2014-
> 12/msg01352.html
> 

That should work, but if viridian is off then I'll still need a fall-back. Is 
viridian always on in EC2?

Thanks,

  Paul

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

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