Attached are a couple patches that would be nice to drop into xen. I wouldn't be overly heart broken if we just close this bug as wont-fix, but I think these are at least worth discussing, so I'm writing the bug in case we decide to post them. Feel free to add more...
Created attachment 505218 [details] [PATCH] xen: double debug ring buffer size 16k is too small to be useful. xend python code already supports 32k. Unfortunately xenconsoled is also set at 16k and needs to be updated to support this change. --- drivers/char/console.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-)
Created attachment 505219 [details] [PATCH] xen: always set nr_cpus to 256 for x86_64 builds Developers generally just type 'make' to build test hypervisors. This patch makes sure they always get NR_CPUS set to 256 for x86_64 builds, otherwise the test hypervisor would only have 32 and may not test things correctly. --- include/asm-x86/config.h | 2 ++ 1 files changed, 2 insertions(+), 0 deletions(-)
Created attachment 505220 [details] [PATCH] xen: get rid of debug log spam This message is useless and spams the logs when debug messages are turned on. Just get rid of it. --- common/sysctl.c | 6 ++---- 1 files changed, 2 insertions(+), 4 deletions(-)
(In reply to comment #1) > Unfortunately xenconsoled is also set at 16k and needs to be updated > to support this change. The xenconsoled change would be here in console/daemon/io.c 782 static void handle_hv_logs(void) 783 { 784 char buffer[1024*16];
I agree about the last two patches. For the first, it is risky (what about updates to kernel-xen before xen?) and anyway any fixed value is useless. To work properly with debug output you need a serial console. :(
Created attachment 520346 [details] bump default NR_CPUS to 256 on x86_64; get rid of debug log spam not doubling xm dmesg ringbuf size as per comment 5 I built an x86_64 binary locally, without explicitly passing max_phys_cpus=256 as usual. Tested on my workstation with virt-manager, the debug log spam disappeared when compared to -281. Tested on "dell-per815-02.lab.bos.redhat.com" with "xm info", "nr_cpus" is "48". Brew in progress: https://brewweb.devel.redhat.com/taskinfo?taskID=3588923
(In reply to comment #6) > Created attachment 520346 [details] > bump default NR_CPUS to 256 on x86_64; get rid of debug log spam NR_CPUS change mailed to upstream: http://lists.xensource.com/archives/html/xen-devel/2011-08/msg01208.html
This request was evaluated by Red Hat Product Management for inclusion in a Red Hat Enterprise Linux maintenance release. Product Management has requested further review of this request by Red Hat Engineering, for potential inclusion in a Red Hat Enterprise Linux Update release for currently deployed products. This request is not yet committed for inclusion in an Update release.
Patch(es) available in kernel-2.6.18-284.el5 You can download this test kernel (or newer) from http://people.redhat.com/jwilson/el5 Detailed testing feedback is always welcomed.
https://bugzilla.redhat.com/show_bug.cgi?id=714053 Verified with kernel-xen-2.6.18-300.el5. Before the fix, I built a x86_64 hypervisor (no max_phys_cpus specified), then boot up the hypervisor on a host with 64 cpus, xm info show nr_cpus = 32. After the fix, the xm info show correct number of cpus. And before the fix, there are messages of "(XEN) sysctl.c:51: Allowing physinfo call with newer ABI version" printed in xm dmesg when virt-manager start. After the fix, there is no such message anymore.
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. http://rhn.redhat.com/errata/RHSA-2012-0150.html