[PATCH] pvops: Avoid re-alloc_intr_gate of hvm evtchn callback

[PATCH] pvops: Avoid re-alloc_intr_gate of hvm evtchn callback

[Frank Pan]

[-- Attachment #1: Type: text/plain, Size: 1199 bytes --]

I've met a issue that a PV-on-HVM domain become stucked after migration.
The alloc_intr_gate(HVM_XEN_EVTCHN_CALLBACK) is called the second time
after the migration and leads to BUG(). (The first time is at system
initialization)

The following patch fixes this by check whether this callback is
registered or not before calling alloc_intr_gate.
---
 linux-2.6-xen/drivers/xen/events.c |    4 +++-
 1 files changed, 3 insertions(+), 1 deletions(-)

diff --git a/linux-2.6-xen/drivers/xen/events.c
b/linux-2.6-xen/drivers/xen/events.c
index ac7b42f..77ffceb 100644
--- a/linux-2.6-xen/drivers/xen/events.c
+++ b/linux-2.6-xen/drivers/xen/events.c
@@ -1500,7 +1500,9 @@ void xen_callback_vector(void)
 		}
 		printk(KERN_INFO "Xen HVM callback vector for event delivery is "
 				"enabled\n");
-		alloc_intr_gate(XEN_HVM_EVTCHN_CALLBACK, xen_hvm_callback_vector);
+		/* xen_callback_vector will be called after every domU resume */
+		if (!test_bit(XEN_HVM_EVTCHN_CALLBACK, used_vectors))
+			alloc_intr_gate(XEN_HVM_EVTCHN_CALLBACK, xen_hvm_callback_vector);
 	}
 }
 #else
-- 
1.7.0.4


-- 
潘震皓, Frank Pan

Computer Science and Technology
Tsinghua University

[-- Attachment #2: 0001-Avoid-re-alloc_intr_gate-of-hvm-evtchn-callback.patch --]
[-- Type: text/x-patch, Size: 1295 bytes --]

From dc04b1fbddbc428bb1453187a69be88a036a5d1e Mon Sep 17 00:00:00 2001
From: Frank Pan <frankpzh@gmail.com>
Date: Sat, 5 Mar 2011 16:16:45 +0800
Subject: [PATCH] Avoid re-alloc_intr_gate of hvm evtchn callback

I've met a issue that a PV-on-HVM domain become stucked after migration.
The alloc_intr_gate(HVM_XEN_EVTCHN_CALLBACK) is called the second time after the migration and leads to BUG(). (The first time is at system initialization)

The following patch fixes this by check whether this callback is registered or not before calling alloc_intr_gate.
---
 linux-2.6-xen/drivers/xen/events.c |    4 +++-
 1 files changed, 3 insertions(+), 1 deletions(-)

diff --git a/linux-2.6-xen/drivers/xen/events.c b/linux-2.6-xen/drivers/xen/events.c
index ac7b42f..77ffceb 100644
--- a/linux-2.6-xen/drivers/xen/events.c
+++ b/linux-2.6-xen/drivers/xen/events.c
@@ -1500,7 +1500,9 @@ void xen_callback_vector(void)
 		}
 		printk(KERN_INFO "Xen HVM callback vector for event delivery is "
 				"enabled\n");
-		alloc_intr_gate(XEN_HVM_EVTCHN_CALLBACK, xen_hvm_callback_vector);
+		/* xen_callback_vector will be called after every domU resume */
+		if (!test_bit(XEN_HVM_EVTCHN_CALLBACK, used_vectors))
+			alloc_intr_gate(XEN_HVM_EVTCHN_CALLBACK, xen_hvm_callback_vector);
 	}
 }
 #else
-- 
1.7.0.4


[-- Attachment #3: Type: text/plain, Size: 138 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

Re: [PATCH] pvops: Avoid re-alloc_intr_gate of hvm evtchn callback

[Ian Campbell]

On Sat, 2011-03-05 at 10:11 +0000, Frank Pan wrote:
> I've met a issue that a PV-on-HVM domain become stucked after migration.
> The alloc_intr_gate(HVM_XEN_EVTCHN_CALLBACK) is called the second time
> after the migration and leads to BUG(). (The first time is at system
> initialization)
> 
> The following patch fixes this by check whether this callback is
> registered or not before calling alloc_intr_gate.

Thanks. I presume this is against xen/next-2.6.32? Please always mention
which branch a patch is for.

The upstream kernel already has this check, and it came from the
original commit 38e20b07efd5 "x86/xen: event channels delivery on HVM"
so it looks like the version in the 2.6.32 branch (b24870f7dd7a) was an
older revision of that patch which lacked this check.

I think it would be useful to mention this in the commit message, and
perhaps to use the same comment as upstream to reduce the diff when
comparing the upstream and 2.6.32 branches.

Also your patches need to include a Signed-off-by line in accordance
with Documentation/SubmittingPatches.

Perhaps you might find it useful to do a sweep through
        git://xenbits.xen.org/people/ianc/linux-2.6.git debian/squeeze/pvhvm-2.6.32.24
comparing it to the xen/next-2.6.32 branch?

This is a branch I prepared for the Debian Squeeze kernel which contains
a backport of the upstreamed pvhvm support onto pristine (not xen.git)
2.6.32.24. You may find other differences between the xen/next-2.6.32
branch and upstream which represent changes made during the upstreaming
process. If those are bugfixes it would be useful to suggest them for
backport (if so please identify the upstream commit rather than
providing a fresh patch). Although remember that not all the differences
you see will relate to PVHVM or necessarily be bugfixes.

Thanks,
Ian.

> ---
>  linux-2.6-xen/drivers/xen/events.c |    4 +++-
>  1 files changed, 3 insertions(+), 1 deletions(-)
> 
> diff --git a/linux-2.6-xen/drivers/xen/events.c
> b/linux-2.6-xen/drivers/xen/events.c
> index ac7b42f..77ffceb 100644
> --- a/linux-2.6-xen/drivers/xen/events.c
> +++ b/linux-2.6-xen/drivers/xen/events.c
> @@ -1500,7 +1500,9 @@ void xen_callback_vector(void)
>  		}
>  		printk(KERN_INFO "Xen HVM callback vector for event delivery is "
>  				"enabled\n");
> -		alloc_intr_gate(XEN_HVM_EVTCHN_CALLBACK, xen_hvm_callback_vector);
> +		/* xen_callback_vector will be called after every domU resume */
> +		if (!test_bit(XEN_HVM_EVTCHN_CALLBACK, used_vectors))
> +			alloc_intr_gate(XEN_HVM_EVTCHN_CALLBACK, xen_hvm_callback_vector);
>  	}
>  }
>  #else
> -- 
> 1.7.0.4
> 
> 

Re: [PATCH] pvops: Avoid re-alloc_intr_gate of hvm evtchn callback

[Frank Pan]

> Thanks. I presume this is against xen/next-2.6.32? Please always mention
> which branch a patch is for.

FP: Yes, I'll mention it if I have more bugfixes.

> The upstream kernel already has this check, and it came from the
> original commit 38e20b07efd5 "x86/xen: event channels delivery on HVM"
> so it looks like the version in the 2.6.32 branch (b24870f7dd7a) was an
> older revision of that patch which lacked this check.
>
> Perhaps you might find it useful to do a sweep through
>        git://xenbits.xen.org/people/ianc/linux-2.6.git debian/squeeze/pvhvm-2.6.32.24
> comparing it to the xen/next-2.6.32 branch?

FP: I just want a usable version of pvops for doing some research on
migration. Can you suggest a branch which is not too old and a sort of
stable?

> Also your patches need to include a Signed-off-by line in accordance
> with Documentation/SubmittingPatches.

FP: Gmail sucks on line wrapping, so I also attach the patch inside.
Is that ok? If so, where should I put the "Signed-off-by" line? both?

-- 
潘震皓, Frank Pan

Computer Science and Technology
Tsinghua University

Re: [PATCH] pvops: Avoid re-alloc_intr_gate of hvm evtchn callback

[Ian Campbell]

On Sat, 2011-03-05 at 11:45 +0000, Frank Pan wrote:
> > Thanks. I presume this is against xen/next-2.6.32? Please always mention
> > which branch a patch is for.
> 
> FP: Yes, I'll mention it if I have more bugfixes.

Thanks.

> > The upstream kernel already has this check, and it came from the
> > original commit 38e20b07efd5 "x86/xen: event channels delivery on HVM"
> > so it looks like the version in the 2.6.32 branch (b24870f7dd7a) was an
> > older revision of that patch which lacked this check.
> >
> > Perhaps you might find it useful to do a sweep through
> >        git://xenbits.xen.org/people/ianc/linux-2.6.git debian/squeeze/pvhvm-2.6.32.24
> > comparing it to the xen/next-2.6.32 branch?
> 
> FP: I just want a usable version of pvops for doing some research on
> migration. Can you suggest a branch which is not too old and a sort of
> stable?

For PV domU any modern mainline (e.g. kernel.org) kernel should be fine.

PVHVM domU support first landed upstream in 2.6.37 so that is the
minimum version for that, but again it should be fine for domU use. I'd
recommend tracking the upstream 2.6.x.y stable trees -- e.g 2.6.37.2
right now.

> > Also your patches need to include a Signed-off-by line in accordance
> > with Documentation/SubmittingPatches.
> 
> FP: Gmail sucks on line wrapping, so I also attach the patch inside.
> Is that ok? If so, where should I put the "Signed-off-by" line? both?

Might as well put it in both.

Ian.