Hi Keir,

Thanks for the response. My comments bellow.

From: Keir Fraser [mailto:keir@xxxxxxxxxxxxx]

Some comments:
1. Use of cpumaps in the sysctl interface assumes no more than 64 CPUs. We got rid of that assumption everywhere else. You don’t really need the cpumaps anyway — tools can deduce them from other information (e.g., matching up core/package ids across cpus).

Makes sense to me. It was kind of extra information. I was trying to provide as much information as a user can get running on native Linux kernel.

2. The cacheinfo call is heinously Intel specific, especially the ‘type’ field which corresponds to a bitfield from an Intel-specific CPUID leaf. What is returned if the cacheinfo is requested on an older Intel box or on an AMD, Via, Transmeta, etc. CPU?

Yes I agree that cacheinfo code in the patch I sent is very Intel specific. If the same code will not run on other x86 cpus, And the xm command is not going to provide any information at all. This is because it checks for Intel processor in the hyper visor to get this information. The purpose of providing this information is to enable the administrator/end user to make a better decision on assigning physical CPUs to different VMs. And the real use this information is with the multi-core or hyper-threaded processors. I am assuming that other people will extend this code to support other x86 and non-x86 multi-core processors.

3. What are these calls for? Beyond dumping a lot of info in a new xm call, who is wanting this detailed info? Particularly on the cacheinfo side I could imagine some apps wanting to know what resource they have to play with, but these sysctls are available only to dom0. And those apps will probably just go straight at CPUID anyway, and assume the cache hierarchy is symmetric (a reasonably safe assumption really).

This information is for administrator/end user of the system to make better decisions about partitioning the processors in the system across multiple domains. Dom0 may not be running on all the CPUs in the system, so this gives a view from hyper visor about all the CPUs that hyper visor sees. And also the cache info may not always be symmetric in the system.

Let me know if you have any further concerns.

-- Keir

On 9/12/06 1:41 am, "Kamble, Nitin A" <nitin.a.kamble@xxxxxxxxx> wrote:

Hi Keir, Ian,
Attached is a patch which implements “xm cpuinfo” and “xm cacheinfo” commands. Output of these commands on a 4 way paxville (2 core per socket, 2 threads per core) and 2 way clovertown (Quadcore) system is shown bellow.
It would be easy to extend this functionality to other architectures such as IA64 or power by reusing most of the code. Other architectures would need to implement switch-cases XEN_SYSCTL_cpuinfo: & XEN_SYSCTL_cacheinfo: in their arch_do_sysctl() in the function hyper visor to get this functionality.

The Changes are distributed in 3 areas viz hyper visor, libxc and python code as seen in the diffstat bellow.

Please apply and/or provide comments for the patch.