| |
|
 |
|
 |
|
|
|
| |
|
|
xen-devel
Re: [Xen-devel] First release candidate for 3.2.0
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
|
|
|
| |
|
Home