similar to: auto-ballooning crashing Dom0?

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.

Is there any reason why I would not want to set dom0-min-mem to 0 or to what I set dom0_mem on my kernel line? Setting to 0 or setting to the same value as dom0_mem disables memory balloon correct? I cant seem to think of a reason why I would want memory ballooning. Also setting dom0-min-mem should that be done in xend-config.sxp or on the kernel command line? -- Nick Anderson

# HG changeset patch # User Ian Campbell <ijc@hellion.org.uk> # Date 1354011148 0 # Node ID 3174dc24e3efb0c5b964c244dbfb0218a03a38cf # Parent 541b0e1a36c86db5df04988dd4ade5430776a7f2 xl: xl.conf(5): correct advice re autoballooning vs. dom0_mem. The advice was backwards, you should really disable autoballoon if you use dom0_mem. Also add a reference to the command-line docs.

From: David Vrabel <david.vrabel@citrix.com> autoballoon=1 is not recommened if dom0_mem was used to reduce the amount of dom0 memory. Instead of requiring users to change xl.conf if they do this, extend the autoballoon option with a new choice: "auto". With autoballoon="auto", autoballooning will be disabled if dom0_mem was used on the Xen command line. For

On Thu, 2013-09-05 at 20:52 +0200, Alessandro Vesely wrote: > Package: xen-hypervisor-4.1-amd64 > Version: 4.1.4-3+deb7u1 > Severity: normal > > I tried GRUB_CMDLINE_XEN="dom0_mem=8192M": that delivers 6964868K total, then > crashes when used=2837436K free=4127432K. > By crash I mean the gnome screen was blown away, replaced by a black screen > with white log

Hi! i notice a serious regression with 3.5 as Dom0 kernel (3.4 was rock stable): 1st: only the GPU PCI Passthrough works, the PCI USB Controller is not recognized within the DomU (HVM Win7 64) Dom0 cmdline is: ro root=LABEL=dom0root xen-pciback.hide=(08:00.0)(08:00.1)(00:1d.0)(00:1d.1)(00:1d.2)(00:1d.7) security=apparmor noirqdebug nouveau.msi=1 Only 8:00.0 and 8:00.1 get passed through

Hello, I recently swapped some components, and rebuilt my system. Changes to the configuration: - Wheezy Beta 1 > Wheezy Beta 2 - Kernel 3.4.9 > Kernel 3.4.11 I have tested the new Xen 4.2 stable, and Xen unstable revision 25777, both are giving me the same error so I do not believe it is related to a change in Xen. The first attempt to pass a PCI device after booting the system

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

Hi all, I'm having issue with my Centos 5.1 /Xen installation. I'm having some dom0 running 2.6.18-53.1.6.el5xen (x86_64). On the dom0 where the load is high (more than 70% of total system memory consumed by dom0 and domU) we have a lot of "memory squeeze ". The result is that the domU seems to be blocked (no network/no disk acces/ etc....). Looking for a solution in xen

Package: xen-hypervisor-4.1-amd64 Version: 4.1.2-2 When installing xen-linux-system on a new Dell R810 server, Wheezy, Squeeze and Ubuntu server 11.10 all boot fine when booted directly into the standard kernel, but when booting through Xen (after installing the package xen-linux-system) the boot process hangs as soon as Xen passes control to the Dom0 kernel: "Gave up waiting for root

Hi List, I have just two basic questions: 1) should I set for example dom0_mem=2048M at grub? 2) should I set xm mem-max 0 4000 ? irsh # dominfo 0 Id: 0 Name: Domain-0 UUID: 00000000-0000-0000-0000-000000000000 OS Type: linux State: running CPU(s): 8 CPU time: 115.3s Max memory: 4096000 kB Used memory: 2075136 kB Autostart:

I''m trying to configure GRUB to allocate fixed amount of dedicated memory to dom0, according to this best practices thread (http://wiki.xensource.com/xenwiki/XenBestPractices | "Xen dom0 dedicated memory and preventing dom0 memory ballooning "). When I reboot, dom0 has the fixed amount of memory as it was configured, but neither xm info shows the rest of memory available

We have some test servers running SLES11SP1 and we''ve updated to the latest kernel from Novell: 2.6.32.13-0.5-xen Since running the updates on these servers our xen ballooning parameters are not working. Because of memory problems in the past we set dom0 to 2048 meg of ram in grub and set the following parameters in /etc/xen/xend-config.sxp: (dom0-min-mem 2048) (enable-dom0-ballooning

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

Hello, this is a question I wanted to ask you since a long time because there is something not too much clear to me, as regard the memory management in XEN. I don''t want to go too much in deep with such argument, but It''s just to understand what is the best setup for my environment. I know about memory ballooning (http://wiki.xensource.com/xenwiki/XenBestPractices) and the

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, 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, 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, All the reviews for the AMD 890fx chipset reported that it supports IOMMU v1.2. But I cannot find any mention of that on AMD site. Does 890fx support IOMMU? Do 890fx motherboards with IOMMU exist? Does Xen support 890fx? Regards, Leonardo _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel

Hi, if there is no UUID specified in the config file, we generate one during the _parsing_ process. Since xl list -l parses the config file again, the UUID will be generated again in this case and the reported version does probably not match the used one. Fix this by retrieving the UUID from dominfo (like xl list -v does). Signed-off-by: Andre Przywara <andre.przywara@amd.com> Regards,