[PATCH] fixes to stable/for-linus-3.5

[PATCH] fixes to stable/for-linus-3.5

[Konrad Rzeszutek Wilk]

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.

[PATCH 1/2] xen/smp: unbind irqworkX when unplugging vCPUs.

[Konrad Rzeszutek Wilk]

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

[PATCH 2/2] xen/setup: Work properly with 'dom0_mem=X' or with not dom0_mem.

[Konrad Rzeszutek Wilk]

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

Re: [Xen-devel] [PATCH] fixes to stable/for-linus-3.5

[David Vrabel]

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

Re: [Xen-devel] [PATCH] fixes to stable/for-linus-3.5

[Konrad Rzeszutek Wilk]

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/