Xen devel - Jul 2007 - [Xen-ia64-devel] [Patch 0/2] Disable ACPI SRAT,SLIT on dom0

Hi, Keir, Alex and all

On some ia64 NUMA machine, we cannot boot dom0.
This issue is caused by different infomation LSAPIC and SRAT.
Xen-ia64 modify LSAPIC IDs of dom0, but it does not modify SRAT.

Currently, credit scheduler does not consider NUMA system.
And Xen-ia64 pass raw ACPI SRAT, SLIT infomation to dom0.
If xen pass NUMA infomation to dom0, dom0 cannot move properly
because vcpus can migrate and memory mapping is virtualized.
So we decide disabling SRAT, SLIT of dom0 as first step of NUMA work.

[Patch 1/2] is for common code, and [Patch 2/2] is for ia64.

[Patch 1/2] Export acpi a function and arguments
[Patch 2/2] Disable ACPI SRAT,SLIT on dom0

Best Regards,

Akio Takebe


_______________________________________________
Xen-ia64-devel mailing list
Xen-ia64-devel@lists.xensource.com
http://lists.xensource.com/xen-ia64-devel

Hi,

This path export some symbols of acpi.

Signed-off-by: Akio Takebe <takebe_akio@jp.fujitsu.com>

Best Regards,

Akio Takebe


_______________________________________________
Xen-ia64-devel mailing list
Xen-ia64-devel@lists.xensource.com
http://lists.xensource.com/xen-ia64-devel

Hi,

This patch is to disable SRAT, SLIT on dom0.
This depends on the first patch.
>[Patch 1/2] Export acpi a function and arguments
Signed-off-by: Akio Takebe <takebe_akio@jp.fujitsu.com>

Best Regards,

Akio Takebe

_______________________________________________
Xen-ia64-devel mailing list
Xen-ia64-devel@lists.xensource.com
http://lists.xensource.com/xen-ia64-devel

On Fri, 2007-07-27 at 03:06 +0900, Akio Takebe wrote:
> Hi, Keir, Alex and all
> 
> On some ia64 NUMA machine, we cannot boot dom0.
> This issue is caused by different infomation LSAPIC and SRAT.
> Xen-ia64 modify LSAPIC IDs of dom0, but it does not modify SRAT.
> 
> Currently, credit scheduler does not consider NUMA system.
> And Xen-ia64 pass raw ACPI SRAT, SLIT infomation to dom0.
> If xen pass NUMA infomation to dom0, dom0 cannot move properly
> because vcpus can migrate and memory mapping is virtualized.
> So we decide disabling SRAT, SLIT of dom0 as first step of NUMA work.
   Would it make more sense to create the acpi_table_disable() and
support functions in the common acpi code?  The only ia64 specific parts
of the implementation appear to be writing "XenIPF" for the OEM ID and
calling generate_acpi_checksum().  The latter could easily be moved, or
maybe we could make use of acpi_table_compute_checksum().  The new OEM
ID could be passed into the function, but it might be just as useful to
write the original table signature into the OEM ID field so we know what
it was (ex. "xSRATx").  Thanks,

	Alex

-- 
Alex Williamson                             HP Open Source & Linux Org.


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

Hi, Alex and Keir
>   Would it make more sense to create the acpi_table_disable() and
>support functions in the common acpi code?  The only ia64 specific parts
>of the implementation appear to be writing "XenIPF" for the OEM ID
and
>calling generate_acpi_checksum().  The latter could easily be moved, or
>maybe we could make use of acpi_table_compute_checksum().  The new OEM
>ID could be passed into the function, but it might be just as useful to
>write the original table signature into the OEM ID field so we know what
>it was (ex. "xSRATx").  Thanks,
Exactly, I want to move them to common code. 
Keir, is this good?

BTW, we may rewrite also OEM Table ID.
How about the below?

signature    = OEMx
OEM ID       = xSRATx
OEM table ID = Xen

Best Regards,

Akio Takebe


_______________________________________________
Xen-ia64-devel mailing list
Xen-ia64-devel@lists.xensource.com
http://lists.xensource.com/xen-ia64-devel

Yes, if you want to generally screw around with ACPI info -- disabling
tables, changing OEM IDs, etc -- then it makes sense to put the mechanism in
common code, but call those new routines from arch code (so that different
architectures have different policies about how they modify the tables).

 -- Keir

On 26/7/07 20:14, "Akio Takebe" <takebe_akio@jp.fujitsu.com>
wrote:
> Exactly, I want to move them to common code.
> Keir, is this good?
> 
> BTW, we may rewrite also OEM Table ID.
> How about the below?
> 
> signature    = OEMx
> OEM ID       = xSRATx
> OEM table ID = Xen


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