[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
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |