similar to: [PATCH] xl: fix UUID reporting with xl list -l

Hi, although advertised via the usage output, xl cpupool-list -l just returns ERROR_NI, which does not show up on the console. Instead the output is empty, which is not exactly what --long hints to. To avoid confusion remove the line from the help output and just ignore the -l option properly until it gets finally implemented. Signed-off-by: Andre Przywara <andre.przywara@amd.com>

Hi, xl is currently ignoring the cpuid= variable in the config file. As I don''t like the current interface xm exposes (basically because it is complicated, unintuitive and very error prone), I implemented a new scheme for specifying CPUID flags policy, combining QEMU''s and Xen''s approach: cpuid = "<base>,<feature_name>=[01xks]*,... The patch includes a

Hi, the implementation of xl cpupool-numa-split is broken. It basically deals with only one poolid, but there are two to consider: the one from the original root CPUpool, the other from the newly created one. On my machine the current output looks like: root@dosorca:/data/images# xl cpupool-numa-split libxl: error: libxl.c:2803:libxl_create_cpupool Could not create cpupool error on creating

Hi, the attached patch makes Xen tracing work again, after the introduction of the hypercall buffers broke it. Just a missing line. Thanks to Uwe Dannowski for reporting this. Signed-off-by: Andre Przywara <andre.przywara@amd.com> Regards, Andre. -- Andre Przywara AMD-Operating System Research Center (OSRC), Dresden, Germany Tel: +49 351 448-3567-12

Hi, currently we go through the emulator every time a HVM guest does an I/O port access (in/out). This is unnecessary most of the times, as both VMX and SVM provide all the necessary information already in the VMCS/VMCB. String instructions are not covered by this shortcut, but they are quite rare and we would need to access the guest memory anyway. This patch decodes the information from

Hi, this one actually parses the cpuid option string and translates it into the 32-character string libxc expects. Please comment! Signed-off-by: Andre Przywara <andre.przywara@amd.com> -- Andre Przywara AMD-Operating System Research Center (OSRC), Dresden, Germany Tel: +49 351 448-3567-12 _______________________________________________ Xen-devel mailing list

Hi, this patch introduces a new config file option (numanodes=[x]) to specify a list of valid NUMA nodes for guests. This will extend (but not replace) the recently introduced automatic placement. If several nodes are given, the current algorithm will choose one of them. If none of the given nodes has enough memory, this will fall back to the automatic placement. Signed-off-by: Andre

Hi, during some experiments with many guests I get crashing Dom0s because of too less memory. Actually the OOM killer goes ''round and kills random things, preferably qemu-dm''s ;-) The box in question has 128GB of memory, I start with dom0_mem=8192M (or 16384M, doesn''t matter). I also used "dom0_mem=8192M,min:1536M", but that didn''t make any

Hi, while testing some APERF/MPERF semantics I discovered that this feature is enabled in Xen Dom0, but is not reliable. The Linux kernel''s scheduler uses this feature if it sees the CPUID bit, leading to costly RDMSR traps (a few 100,000s during a kernel compile) and bogus values due to VCPU migration during the measurement. The attached patch explicitly disables this CPU capability

When dumping heap info (using the Xen console handlers, e.g. CTRL-a) there are entries printed for each node and zone combination. This is helpful, but summarizing the node''s memory usage would be better. This patch adds three lines per node after the heap dump. The first line shows the number of DMA-capable pages, the second one the number of higher pages, the third is the sum of

To make use of the new node aware memop hypercall, the xc_domain_memory_populate_physmap function is extended by a node parameter. Passing XENMEM_DEFAULT_NODE mimics the current behavior. Signed-off-by: Andre Przywara <andre.przywara@amd.com> -- Andre Przywara AMD-Operating System Research Center (OSRC), Dresden, Germany Tel: +49 351 277-84917 ----to satisfy European Law for business

Hi, we have some problems with acpidump running on Xen Dom0. On 64 bit Dom0 it will trigger the OOM killer, on 32 bit Dom0s it will cause a kernel crash. The hypervisor does not matter, I tried 4.1.3-rc2 as well as various unstable versions including 25467, also 32-bit versions of 4.1. The Dom0 kernels were always PVOPS versions, the problems starts with 3.2-rc1~194 and is still in 3.5.0-rc3.

The current early-printk support for ARM is rather hard-coded, making it hard to add machines or tweak settings. This series slightly moves some code to gather UART settings in xen/arch/arm/Rules.mk instead of the actual .c files. Also it allows two different machines with different settings to share the same driver, which the last patch exploits to add support the Calxeda Midway hardware. This

docs/man/xl.pod.1 | 6 +++++- tools/libxl/xl_cmdimpl.c | 39 ++++++++++++++++++++++++++++++++++++--- tools/libxl/xl_cmdtable.c | 3 ++- 3 files changed, 43 insertions(+), 5 deletions(-) xl: Introduce shutdown xm compatibility option -a to shutdown all domains Signed-off-by: Sander Eikelenboom <linux@eikelenboom.it> diff -r 9dc729b75595 -r 67f9ef649937 docs/man/xl.pod.1 ---

flight 18753 xen-unstable real [real] http://www.chiark.greenend.org.uk/~xensrcts/logs/18753/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-xl-win7-amd64 8 guest-saverestore fail REGR. vs. 18750 Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-pcipt-intel 9 guest-start fail

flight 5665 xen-unstable real [real] http://www.chiark.greenend.org.uk/~xensrcts/logs/5665/ Regressions :-( Tests which did not succeed and are blocking: build-amd64-oldkern 4 xen-build fail REGR. vs. 5640 build-amd64 4 xen-build fail REGR. vs. 5640 build-i386-oldkern 4 xen-build fail REGR. vs. 5640

flight 21930 qemu-upstream-unstable real [real] http://www.chiark.greenend.org.uk/~xensrcts/logs/21930/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-qemuu-rhel6hvm-intel 7 redhat-install fail REGR. vs. 20054 Tests which are failing intermittently (not blocking): test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 7

flight 21993 qemu-upstream-unstable real [real] http://www.chiark.greenend.org.uk/~xensrcts/logs/21993/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-qemuu-rhel6hvm-intel 7 redhat-install fail REGR. vs. 20054 Tests which are failing intermittently (not blocking): test-amd64-amd64-xl-qemuu-win7-amd64 8

flight 21952 qemu-upstream-unstable real [real] http://www.chiark.greenend.org.uk/~xensrcts/logs/21952/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-qemuu-rhel6hvm-intel 7 redhat-install fail REGR. vs. 20054 Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-qemuu-win7-amd64 13 guest-stop

flight 19723 xen-unstable real [real] http://www.chiark.greenend.org.uk/~xensrcts/logs/19723/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-pv 9 guest-start fail REGR. vs. 19708 test-amd64-i386-xend-winxpsp3 8 guest-saverestore fail REGR. vs. 19708 test-amd64-i386-pv 9