Re: Workings/effectiveness of the xen-acpi-processor driver

[Stefan Bader <stefan.bader@canonical.com>]

[-- Attachment #1.1: Type: text/plain, Size: 1636 bytes --]

On 03.05.2012 14:58, Stefan Bader wrote:

>>>>> 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)
> 
> I added debugging to all exit paths that could return 0 (which is what the
> boot_cpu_physical_apicid is set to with that patch. Which would only leave the
> case of the HV call returning the wrong value somehow...
> 
Hmmm, so xen_apic_read is still correct...

[    0.000000] ACPI: Local APIC address 0xfee00000
[    0.000000] xxx xen_apic_read(20)
[    0.000000] xxx xen_apic_read -> 10
[    0.000000] boot_cpu_physical_apicid = 0
[    0.000000] xxx xen_apic_read(30)
[    0.000000] +- apic version = 10

there seems to be a slightly strange tweak (at least for me) in read_apic_id...

static inline unsigned int read_apic_id(void)
{
        unsigned int reg;

        reg = apic_read(APIC_ID); // calls apic->read(reg)

        return apic->get_apic_id(reg);
}



[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 900 bytes --]

[-- Attachment #2: Type: text/plain, Size: 126 bytes --]

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