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

[Keir Fraser <Keir.Fraser@xxxxxxxxxxxx>]

On 12/12/07 14:50, "John Levon" <levon@xxxxxxxxxxxxxxxxx> wrote:

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

Well, you may over-estimate total RAM by up to about a gigabyte, depending
on the size of the I/O hole below 4GB. Perhaps that is good enough? It
sounds like you grossly over-estimate anyway. Oh, also there is
XENMEM_machine_memory_map, which returns the physical e820 map. You can
easily parse that to get total RAM.

>> 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?

I think we'd be warning on quite a wide range of AMD CPUs. Number of VCPUs
will work fine unless someone has specified dom0_max_vcpus=1 on the Xen
command line. Alternatively there is now XENPG_getidletime: this can be
(ab)used to find out whether there is more than one physical CPU.

 -- Keir



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