Re: [PATCH] Use x2apic_supported() in the default_apic_id_valid()function.

From: Steffen Persvold
Date: Thu Mar 15 2012 - 19:17:58 EST


On 3/16/2012 00:04, Suresh Siddha wrote:
On Thu, 2012-03-15 at 23:34 +0100, Steffen Persvold wrote:
Is my understanding of your suggestion correct that in
x2apic_phys/cluster.c we add the following apic_id_valid() function :

static int x2apic_apic_id_valid(int apicid)
{
return x2apic_mode || (apicid< 255);
}

Steffen, We can have something like:

static int x2apic_apic_id_valid(int apicid)
{
return 1;
}

and

static int xapic_apic_id_valid(int apicid)
{
return apicid< 255;
}

If we have selected x2apic driver, then we know we are already in x2apic
mode. And also x2apic_uv_x need to use the x2apic version above.

Considering that this function (apic->apic_id_valid()) is called already
in the acpi/boot.c::acpi_parse_x2apic() function is it sufficient enough
to test for x2apic_mode ? Yinghai indicated that x2apic_mode was not set
at this point, thus it was testing cpu_has_x2apic instead ?

If the bios has handed over to us in x2apic mode (or if it is a numachip
platform), then by this point apic driver is already set to the
corresponding x2apic/numachip driver etc. so we should be fine.

When we are in xapic mode, typically there should be no x2apic MADT
entries. And even if there are any (bios not following x2apic spec), the
above xapic_apic_id_valid() check will consider only those x2apic MADT
entries whose id's are less than 255. xapic mode can go into x2apic mode
later but that flow is not supposed to bring up any cpu with apic id>
255. So parsing only entries with apic id< 255 here should be fine.

Hope this clarifies.


Yes, this is now my understanding aswell. Thank you.

I will resend a reviced patch shortly.

Kind regards,
--
Steffen Persvold, Chief Architect NumaChip
Numascale AS - www.numascale.com
Tel: +47 92 49 25 54 Skype: spersvold
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/