[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


  • To: Jan Beulich <jbeulich@xxxxxxxxxx>, <xen-devel@xxxxxxxxxxxxxxxxxxx>
  • From: Keir Fraser <keir@xxxxxxxxxxxxx>
  • Date: Tue, 07 Aug 2007 13:52:59 +0100
  • Delivery-date: Tue, 07 Aug 2007 05:50:53 -0700
  • List-id: Xen developer discussion <xen-devel.lists.xensource.com>
  • Thread-index: AcfY8eHHIGzvRETlEdyCkgAX8io7RQ==
  • Thread-topic: [Xen-devel] dealing with ill DMI table pointer

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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.