Re: [Xen-devel] Workings/effectiveness of the xen-acpi-processor driver

[Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx>]

On Wed, May 02, 2012 at 01:06:34PM -0400, Boris Ostrovsky wrote:
> On 05/02/2012 12:08 PM, Konrad Rzeszutek Wilk wrote:
> >diff --git a/arch/x86/xen/enlighten.c b/arch/x86/xen/enlighten.c
> >index a8f8844..d816448 100644
> >--- a/arch/x86/xen/enlighten.c
> >+++ b/arch/x86/xen/enlighten.c
> >@@ -811,7 +811,29 @@ static void xen_io_delay(void)
> >  #ifdef CONFIG_X86_LOCAL_APIC
> >  static u32 xen_apic_read(u32 reg)
> >  {
> >-    return 0;
> >+    struct xen_platform_op op = {
> >+            .cmd = XENPF_get_cpuinfo,
> >+            .interface_version = XENPF_INTERFACE_VERSION,
> >+            .u.pcpu_info.xen_cpuid = 0,
> 
> 
> Is this always zero? This will probably solve the current problem

Its a CPU number (not tied in to APIC or ACPI IDs).

> but I am wondering whether in the future we might hit another bug
> because this routine will return the same APICID for all VCPUs.

 Later on it does a check for 'smp_processor_id()' - and if
that is anything but zero it will bail out.

So this shoudl solve the problem for the bootup processor.
> 
> -boris
> 
> 
> >+    };
> >+    int ret = 0;
> >+
> >+    /* Shouldn't need this as APIC is turned off for PV, and we only
> >+     * get called on the bootup processor. But just in case. */
> >+    if (!xen_initial_domain() || smp_processor_id())
> >+            return 0;
> >+
> >+    if (reg == APIC_LVR)
> >+            return 0x10;
> >+
> >+    if (reg != APIC_ID)
> >+            return 0;
> >+
> >+    ret = HYPERVISOR_dom0_op(&op);
> >+    if (ret)
> >+            return 0;
> >+
> >+    return op.u.pcpu_info.apic_id;
> >  }
> >
> >  static void xen_apic_write(u32 reg, u32 val)
> >
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel