WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

[Xen-devel] Re: [Xen-ia64-devel] [Patch 0/2] Disable ACPI SRAT, SLIT on

To: Akio Takebe <takebe_akio@xxxxxxxxxxxxxx>
Subject: [Xen-devel] Re: [Xen-ia64-devel] [Patch 0/2] Disable ACPI SRAT, SLIT on dom0
From: Alex Williamson <alex.williamson@xxxxxx>
Date: Thu, 26 Jul 2007 12:27:43 -0600
Cc: xen-devel <xen-devel@xxxxxxxxxxxxxxxxxxx>, xen-ia64-devel <xen-ia64-devel@xxxxxxxxxxxxxxxxxxx>
Delivery-date: Thu, 26 Jul 2007 11:25:44 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <80C7CFAFA27C5Btakebe_akio@xxxxxxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
Organization: HP OSLO R&D
References: <80C7CFAFA27C5Btakebe_akio@xxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
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@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel