Two fixes for the patches that are going for 3.5. The autoballoon one would try to balloon up to E820_MAX when there were no dom0_mem=.. argument. The patch fixes it, and is also makes the dom0_mem=1G case work better (I think?). The other solution would be to use the current_reservation patch I posted a while back to work-around when no dom0_mem= argument is used. The APIC irqworker is a little easier - it did not unbind when unplugging vCPUs leaving an orphan IRQ behind.
Konrad Rzeszutek Wilk
2012-May-21 21:42 UTC
[PATCH 1/2] xen/smp: unbind irqworkX when unplugging vCPUs.
The git commit 1ff2b0c303698e486f1e0886b4d9876200ef8ca5 "xen: implement IRQ_WORK_VECTOR handler" added the functionality to have a per-cpu "irqworkX" for the IPI APIC functionality. However it missed the unbind when a vCPU is unplugged resulting in an orphaned per-cpu interrupt line for unplugged vCPU: 30: 216 0 xen-dyn-event hvc_console 31: 810 4 xen-dyn-event eth0 32: 29 0 xen-dyn-event blkif - 36: 0 0 xen-percpu-ipi irqwork2 - 37: 287 0 xen-dyn-event xenbus + 36: 287 0 xen-dyn-event xenbus NMI: 0 0 Non-maskable interrupts LOC: 0 0 Local timer interrupts SPU: 0 0 Spurious interrupts Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> --- arch/x86/xen/smp.c | 1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/arch/x86/xen/smp.c b/arch/x86/xen/smp.c index 0503c0c..0e95d7c 100644 --- a/arch/x86/xen/smp.c +++ b/arch/x86/xen/smp.c @@ -418,6 +418,7 @@ static void xen_cpu_die(unsigned int cpu) unbind_from_irqhandler(per_cpu(xen_callfunc_irq, cpu), NULL); unbind_from_irqhandler(per_cpu(xen_debug_irq, cpu), NULL); unbind_from_irqhandler(per_cpu(xen_callfuncsingle_irq, cpu), NULL); + unbind_from_irqhandler(per_cpu(xen_irq_work, cpu), NULL); xen_uninit_lock_cpu(cpu); xen_teardown_timer(cpu); -- 1.7.7.5
Konrad Rzeszutek Wilk
2012-May-21 21:42 UTC
[PATCH 2/2] xen/setup: Work properly with ''dom0_mem=X'' or with not dom0_mem.
We ignored the X value and ended up populating up to
max(MAX_DOMAIN_PAGES, last E820_RAM entry).
This fixes it by figuring out how many RAM nr_pages the
hypervisor wanted to provide to us and cap the populate
hypercalls up to that.
The end result is (on a 32GB box):
-Memory: 31779964k/34603008k available (5831k kernel code, 1351620k absent,
1471424k reserved, 2886k data, 692k init)
-(XEN) memory.c:133:d0 Could not allocate order=0 extent: id=0 memflags=0 (15 of
512)
+Memory: 31788256k/34032852k available (5831k kernel code, 1351620k absent,
892976k reserved, 2886k data, 692k init)
with dom0_mem=1G
-Memory: 550608k/12890412k available (5831k kernel code, 1351620k absent,
10988184k reserved, 2886k data, 692k init)
+Memory: 717272k/1049028k available (5831k kernel code, 516k absent, 331240k
reserved, 2886k data, 692k init)
[v1: Details added]
[v2: Redid on 32GB box]
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
---
arch/x86/xen/setup.c | 18 ++++++++++++++++++
1 files changed, 18 insertions(+), 0 deletions(-)
diff --git a/arch/x86/xen/setup.c b/arch/x86/xen/setup.c
index 1ba8dff..23d355c 100644
--- a/arch/x86/xen/setup.c
+++ b/arch/x86/xen/setup.c
@@ -182,11 +182,29 @@ static unsigned long __init xen_get_max_pages(void)
* the current maximum rather than the static maximum. In this
* case the e820 map provided to us will cover the static
* maximum region.
+ *
+ * The dom0_mem=min:X,max:Y tweaks options differently depending
+ * on the version, but in general this is what we get:
+ * | XENMEM_maximum_reser | nr_pages
+ * --------------++-----------------------+-------------------
+ * no dom0_mem | INT_MAX | max_phys_pfn
+ * =3G | INT_MAX | 786432
+ * =max:3G | 786432 | 786432
+ * =min:1G,max:3G| INT_MAX | max_phys_fn
+ * =1G,max:3G | INT_MAX | 262144
+ * =min:1G,max:3G,2G | INT_MAX | max_phys_fn
+ *
+ * The =3G is often used and it lead to us initially setting
+ * 786432 and allowing dom0 to balloon up to the max_physical_pfn.
+ * This is at odd with the classic XenOClassic so lets emulate
+ * the classic behavior.
*/
if (xen_initial_domain()) {
ret = HYPERVISOR_memory_op(XENMEM_maximum_reservation, &domid);
if (ret > 0)
max_pages = ret;
+ if (ret == -1UL)
+ max_pages = xen_start_info->nr_pages;
}
return min(max_pages, MAX_DOMAIN_PAGES);
--
1.7.7.5
On 21/05/12 22:42, Konrad Rzeszutek Wilk wrote:> > The autoballoon one would try to balloon up to E820_MAX when > there were no dom0_mem=.. argument.I don''t see this behaviour and looking at the code I don''t see how it could. The autoballoon code only populates pages that were released so it won''t go above xen_start_info->nr_pages. Do you have any logs showing the problem behaviour?> The patch fixes it, and > is also makes the dom0_mem=1G case work better (I think?). The > other solution would be to use the current_reservation patch > I posted a while back to work-around when no dom0_mem= argument > is used.David
Konrad Rzeszutek Wilk
2012-May-23 17:32 UTC
Re: [Xen-devel] [PATCH] fixes to stable/for-linus-3.5
On Wed, May 23, 2012 at 05:02:33PM +0100, David Vrabel wrote:> On 21/05/12 22:42, Konrad Rzeszutek Wilk wrote: > > > > The autoballoon one would try to balloon up to E820_MAX when > > there were no dom0_mem=.. argument. > > I don''t see this behaviour and looking at the code I don''t see how it > could. The autoballoon code only populates pages that were released so > it won''t go above xen_start_info->nr_pages.You are right. The ballooning up seems to be done by some other piece of code.> > Do you have any logs showing the problem behaviour?I did. Let me re-run it and send it along.> > > The patch fixes it, and > > is also makes the dom0_mem=1G case work better (I think?). The > > other solution would be to use the current_reservation patch > > I posted a while back to work-around when no dom0_mem= argument > > is used. > > David > -- > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/