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

Re: [Xen-devel] dealing with ill DMI table pointer

To: Jan Beulich <jbeulich@xxxxxxxxxx>, <xen-devel@xxxxxxxxxxxxxxxxxxx>
Subject: Re: [Xen-devel] dealing with ill DMI table pointer
From: Keir Fraser <keir@xxxxxxxxxxxxx>
Date: Tue, 07 Aug 2007 13:52:59 +0100
Delivery-date: Tue, 07 Aug 2007 05:50:53 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <46B885CE.76E4.0078.0@xxxxxxxxxx>
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>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: AcfY8eHHIGzvRETlEdyCkgAX8io7RQ==
Thread-topic: [Xen-devel] dealing with ill DMI table pointer
User-agent: Microsoft-Entourage/11.3.3.061214
I'd be happy to have an early fixup of e820 in Xen, and print a warning,
especially if it's not much code.

 -- Keir

On 7/8/07 13:46, "Jan Beulich" <jbeulich@xxxxxxxxxx> wrote:

> On at least one system we see the DMI table being located in what E820 reports
> as usable RAM. Obviously, native has no immediate issue with this as it (a)
> needs
> the tables only at boot and (b) has no problem ioremap-ing RAM pages. A Xen
> kernel, otoh, is likely to die because of this unless it happens to own the
> page(s).
> 
> The only reasonable workaround I can see would be to have Xen look up the
> DMI table and alter the E820 map by hand if needed (and also avoid to destroy
> the information contained therein, implying that this must be done pretty
> early).
> 
> The only other alternative I see would be to simply say: Bad luck, get a BIOS
> update. But the DMI code in Linux clearly says that this is not a unique
> problem,
> so having some kind of workaround to at least gracefully fail
> dmi_scan_machine()
> might be desirable, but would seem to require propagating an error code from
> set_fixmap() and changing this function to use hypercalls instead of direct
> page
> table writes.
> 
> Jan
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@xxxxxxxxxxxxxxxxxxx
> http://lists.xensource.com/xen-devel


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

<Prev in Thread] Current Thread [Next in Thread>