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

Re: [Xen-devel] First release candidate for 3.2.0



On Wed, Dec 12, 2007 at 02:25:39PM +0000, Keir Fraser wrote:

> > Number of total physical pages
> > 
> > - we ask about this for the benefit of our Xen crash dump
> >  support. This could easily be a platform op I think?
> 
> Would XENMEM_maximum_ram_page be as good or better? If you *really* mean
> number of physical RAM pages then we could add that I suppose. How is it
> useful?

If you remember Nils presentation the way we handle Xen failures is to
hook Xen panics into Solaris crash dumps. We need to estimate the
maximum possible size of the dump: since we include the hypervisor pages
themselves, we use the number of physical pages in the system as an
upper bound. It sounds like maximum_ram_page would work fine.
investigate.

> The TLB flush and C1 ramping errata we have worked around since at least Xen

Suspected as much.

> 3.0.2. Erratum 131 should be worked around by the BIOS (in fact, really all

Indeed, we just warn about it strongly. The point of these checks is
mainly to stop people trying to use totally broken machines. We only do
the CPUs check because we don't want to warn for the UP case where it
doesn't matter.

Though it does occur to me that checking the number of VCPUs would
actually be good enough here. Or would you take a patch to print a
warning from inside Xen itself?

thanks,
john

_______________________________________________
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®.