* xen-unstable: commit commit 63753b3e0dc56efb1acf94fa46f3fee7bc59281c leaves HVM guest dangling after shutdown or destroy. @ 2013-04-20 13:21 Sander Eikelenboom 2013-04-20 18:56 ` Konrad Rzeszutek Wilk 0 siblings, 1 reply; 9+ messages in thread From: Sander Eikelenboom @ 2013-04-20 13:21 UTC (permalink / raw) To: Konrad Rzeszutek Wilk; +Cc: Jan Beulich, xen-devel@lists.xen.org Hi, Commit 63753b3e0dc56efb1acf94fa46f3fee7bc59281c x86: allow VCPUOP_register_vcpu_info to work again on PVHVM guests Leaves HVM guests dangling after shutdown or destroy: xl list gives: (null) 16 0 4 --p--d 11.5 (null) 17 0 1 --ps-d 12.0 (first was destroyed, second shutdown) The actual xl and qemu processes are gone, so guest only seem to be still registered in the hypervisor. Another thing this seems to trigger (and that perhaps needs fixing) is that a "xl shutdown --all --wait" doesn't wait anymore. It returns immediately, probably due to the "nullified" name ? -- Sander ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: xen-unstable: commit commit 63753b3e0dc56efb1acf94fa46f3fee7bc59281c leaves HVM guest dangling after shutdown or destroy. 2013-04-20 13:21 xen-unstable: commit commit 63753b3e0dc56efb1acf94fa46f3fee7bc59281c leaves HVM guest dangling after shutdown or destroy Sander Eikelenboom @ 2013-04-20 18:56 ` Konrad Rzeszutek Wilk 2013-04-20 20:32 ` Sander Eikelenboom 2013-04-23 15:35 ` Roger Pau Monné 0 siblings, 2 replies; 9+ messages in thread From: Konrad Rzeszutek Wilk @ 2013-04-20 18:56 UTC (permalink / raw) To: Sander Eikelenboom; +Cc: Jan Beulich, xen-devel@lists.xen.org Sander Eikelenboom <linux@eikelenboom.it> wrote: >Hi, > >Commit 63753b3e0dc56efb1acf94fa46f3fee7bc59281c x86: allow >VCPUOP_register_vcpu_info to work again on PVHVM guests > >Leaves HVM guests dangling after shutdown or destroy: > >xl list gives: >(null) 16 0 4 --p--d > 11.5 >(null) 17 0 1 --ps-d > 12.0 > >(first was destroyed, second shutdown) > >The actual xl and qemu processes are gone, so guest only seem to be >still registered in the hypervisor. > >Another thing this seems to trigger (and that perhaps needs fixing) is >that a "xl shutdown --all --wait" doesn't wait anymore. >It returns immediately, probably due to the "nullified" name ? Is this only happening with Linux guests? > >-- > >Sander -- Sent from my Android phone with K-9 Mail. Please excuse my brevity. ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: xen-unstable: commit commit 63753b3e0dc56efb1acf94fa46f3fee7bc59281c leaves HVM guest dangling after shutdown or destroy. 2013-04-20 18:56 ` Konrad Rzeszutek Wilk @ 2013-04-20 20:32 ` Sander Eikelenboom 2013-04-23 15:35 ` Roger Pau Monné 1 sibling, 0 replies; 9+ messages in thread From: Sander Eikelenboom @ 2013-04-20 20:32 UTC (permalink / raw) To: Konrad Rzeszutek Wilk; +Cc: Jan Beulich, xen-devel@lists.xen.org Saturday, April 20, 2013, 8:56:06 PM, you wrote: > Sander Eikelenboom <linux@eikelenboom.it> wrote: >>Hi, >> >>Commit 63753b3e0dc56efb1acf94fa46f3fee7bc59281c x86: allow >>VCPUOP_register_vcpu_info to work again on PVHVM guests >> >>Leaves HVM guests dangling after shutdown or destroy: >> >>xl list gives: >>(null) 16 0 4 --p--d >> 11.5 >>(null) 17 0 1 --ps-d >> 12.0 >> >>(first was destroyed, second shutdown) >> >>The actual xl and qemu processes are gone, so guest only seem to be >>still registered in the hypervisor. >> >>Another thing this seems to trigger (and that perhaps needs fixing) is >>that a "xl shutdown --all --wait" doesn't wait anymore. >>It returns immediately, probably due to the "nullified" name ? > Is this only happening with Linux guests? Errr good guess .. yes it seems so, destroying linux guest ends up with the "(null)" entry in xl list. With a windows guest it destroys ok. >> >>-- >> >>Sander ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: xen-unstable: commit commit 63753b3e0dc56efb1acf94fa46f3fee7bc59281c leaves HVM guest dangling after shutdown or destroy. 2013-04-20 18:56 ` Konrad Rzeszutek Wilk 2013-04-20 20:32 ` Sander Eikelenboom @ 2013-04-23 15:35 ` Roger Pau Monné 2013-04-24 9:31 ` George Dunlap 1 sibling, 1 reply; 9+ messages in thread From: Roger Pau Monné @ 2013-04-23 15:35 UTC (permalink / raw) To: Konrad Rzeszutek Wilk Cc: Sander Eikelenboom, Jan Beulich, xen-devel@lists.xen.org On 20/04/13 20:56, Konrad Rzeszutek Wilk wrote: > > > Sander Eikelenboom <linux@eikelenboom.it> wrote: > >> Hi, >> >> Commit 63753b3e0dc56efb1acf94fa46f3fee7bc59281c x86: allow >> VCPUOP_register_vcpu_info to work again on PVHVM guests >> >> Leaves HVM guests dangling after shutdown or destroy: >> >> xl list gives: >> (null) 16 0 4 --p--d >> 11.5 >> (null) 17 0 1 --ps-d >> 12.0 >> >> (first was destroyed, second shutdown) >> >> The actual xl and qemu processes are gone, so guest only seem to be >> still registered in the hypervisor. >> >> Another thing this seems to trigger (and that perhaps needs fixing) is >> that a "xl shutdown --all --wait" doesn't wait anymore. >> It returns immediately, probably due to the "nullified" name ? > > Is this only happening with Linux guests? AFAIK this seems to happen with guests that use VCPUOP_register_vcpu_info (I'm seeing the same on FreeBSD). >> >> -- >> >> Sander > ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: xen-unstable: commit commit 63753b3e0dc56efb1acf94fa46f3fee7bc59281c leaves HVM guest dangling after shutdown or destroy. 2013-04-23 15:35 ` Roger Pau Monné @ 2013-04-24 9:31 ` George Dunlap 2013-04-30 13:55 ` Konrad Rzeszutek Wilk 0 siblings, 1 reply; 9+ messages in thread From: George Dunlap @ 2013-04-24 9:31 UTC (permalink / raw) To: Roger Pau Monné Cc: Sander Eikelenboom, xen-devel@lists.xen.org, Jan Beulich, Konrad Rzeszutek Wilk On Tue, Apr 23, 2013 at 4:35 PM, Roger Pau Monné <roger.pau@citrix.com> wrote: > On 20/04/13 20:56, Konrad Rzeszutek Wilk wrote: >> >> >> Sander Eikelenboom <linux@eikelenboom.it> wrote: >> >>> Hi, >>> >>> Commit 63753b3e0dc56efb1acf94fa46f3fee7bc59281c x86: allow >>> VCPUOP_register_vcpu_info to work again on PVHVM guests >>> >>> Leaves HVM guests dangling after shutdown or destroy: >>> >>> xl list gives: >>> (null) 16 0 4 --p--d >>> 11.5 >>> (null) 17 0 1 --ps-d >>> 12.0 >>> >>> (first was destroyed, second shutdown) >>> >>> The actual xl and qemu processes are gone, so guest only seem to be >>> still registered in the hypervisor. >>> >>> Another thing this seems to trigger (and that perhaps needs fixing) is >>> that a "xl shutdown --all --wait" doesn't wait anymore. >>> It returns immediately, probably due to the "nullified" name ? >> >> Is this only happening with Linux guests? > > AFAIK this seems to happen with guests that use > VCPUOP_register_vcpu_info (I'm seeing the same on FreeBSD). Are we leaving a reference to a page dangling around somewhere? -George ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: xen-unstable: commit commit 63753b3e0dc56efb1acf94fa46f3fee7bc59281c leaves HVM guest dangling after shutdown or destroy. 2013-04-24 9:31 ` George Dunlap @ 2013-04-30 13:55 ` Konrad Rzeszutek Wilk 2013-04-30 13:58 ` George Dunlap 2013-04-30 14:18 ` Jan Beulich 0 siblings, 2 replies; 9+ messages in thread From: Konrad Rzeszutek Wilk @ 2013-04-30 13:55 UTC (permalink / raw) To: George Dunlap Cc: Sander Eikelenboom, xen-devel@lists.xen.org, Jan Beulich, Roger Pau Monné On Wed, Apr 24, 2013 at 10:31:20AM +0100, George Dunlap wrote: > On Tue, Apr 23, 2013 at 4:35 PM, Roger Pau Monné <roger.pau@citrix.com> wrote: > > On 20/04/13 20:56, Konrad Rzeszutek Wilk wrote: > >> > >> > >> Sander Eikelenboom <linux@eikelenboom.it> wrote: > >> > >>> Hi, > >>> > >>> Commit 63753b3e0dc56efb1acf94fa46f3fee7bc59281c x86: allow > >>> VCPUOP_register_vcpu_info to work again on PVHVM guests > >>> > >>> Leaves HVM guests dangling after shutdown or destroy: > >>> > >>> xl list gives: > >>> (null) 16 0 4 --p--d > >>> 11.5 > >>> (null) 17 0 1 --ps-d > >>> 12.0 > >>> > >>> (first was destroyed, second shutdown) > >>> > >>> The actual xl and qemu processes are gone, so guest only seem to be > >>> still registered in the hypervisor. > >>> > >>> Another thing this seems to trigger (and that perhaps needs fixing) is > >>> that a "xl shutdown --all --wait" doesn't wait anymore. > >>> It returns immediately, probably due to the "nullified" name ? > >> > >> Is this only happening with Linux guests? > > > > AFAIK this seems to happen with guests that use > > VCPUOP_register_vcpu_info (I'm seeing the same on FreeBSD). > > Are we leaving a reference to a page dangling around somewhere? <nods> That is my thinking. George, if you would not mind - could you add this to the list of bugs for Xen 4.3 I am responsible for. Thanks. ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: xen-unstable: commit commit 63753b3e0dc56efb1acf94fa46f3fee7bc59281c leaves HVM guest dangling after shutdown or destroy. 2013-04-30 13:55 ` Konrad Rzeszutek Wilk @ 2013-04-30 13:58 ` George Dunlap 2013-04-30 14:18 ` Jan Beulich 1 sibling, 0 replies; 9+ messages in thread From: George Dunlap @ 2013-04-30 13:58 UTC (permalink / raw) To: Konrad Rzeszutek Wilk Cc: Sander Eikelenboom, xen-devel@lists.xen.org, Jan Beulich, Roger Pau Monne On 04/30/2013 02:55 PM, Konrad Rzeszutek Wilk wrote: > On Wed, Apr 24, 2013 at 10:31:20AM +0100, George Dunlap wrote: >> On Tue, Apr 23, 2013 at 4:35 PM, Roger Pau Monné <roger.pau@citrix.com> wrote: >>> On 20/04/13 20:56, Konrad Rzeszutek Wilk wrote: >>>> >>>> >>>> Sander Eikelenboom <linux@eikelenboom.it> wrote: >>>> >>>>> Hi, >>>>> >>>>> Commit 63753b3e0dc56efb1acf94fa46f3fee7bc59281c x86: allow >>>>> VCPUOP_register_vcpu_info to work again on PVHVM guests >>>>> >>>>> Leaves HVM guests dangling after shutdown or destroy: >>>>> >>>>> xl list gives: >>>>> (null) 16 0 4 --p--d >>>>> 11.5 >>>>> (null) 17 0 1 --ps-d >>>>> 12.0 >>>>> >>>>> (first was destroyed, second shutdown) >>>>> >>>>> The actual xl and qemu processes are gone, so guest only seem to be >>>>> still registered in the hypervisor. >>>>> >>>>> Another thing this seems to trigger (and that perhaps needs fixing) is >>>>> that a "xl shutdown --all --wait" doesn't wait anymore. >>>>> It returns immediately, probably due to the "nullified" name ? >>>> >>>> Is this only happening with Linux guests? >>> >>> AFAIK this seems to happen with guests that use >>> VCPUOP_register_vcpu_info (I'm seeing the same on FreeBSD). >> >> Are we leaving a reference to a page dangling around somewhere? > > <nods> That is my thinking. George, if you would not mind - could you add > this to the list of bugs for Xen 4.3 I am responsible for. Done. -George ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: xen-unstable: commit commit 63753b3e0dc56efb1acf94fa46f3fee7bc59281c leaves HVM guest dangling after shutdown or destroy. 2013-04-30 13:55 ` Konrad Rzeszutek Wilk 2013-04-30 13:58 ` George Dunlap @ 2013-04-30 14:18 ` Jan Beulich 2013-05-01 14:35 ` Sander Eikelenboom 1 sibling, 1 reply; 9+ messages in thread From: Jan Beulich @ 2013-04-30 14:18 UTC (permalink / raw) To: George Dunlap, Konrad Rzeszutek Wilk Cc: Sander Eikelenboom, xen-devel@lists.xen.org, roger.pau [-- Attachment #1: Type: text/plain, Size: 2601 bytes --] >>> On 30.04.13 at 15:55, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> wrote: > On Wed, Apr 24, 2013 at 10:31:20AM +0100, George Dunlap wrote: >> On Tue, Apr 23, 2013 at 4:35 PM, Roger Pau Monné <roger.pau@citrix.com> wrote: >> > On 20/04/13 20:56, Konrad Rzeszutek Wilk wrote: >> >> >> >> >> >> Sander Eikelenboom <linux@eikelenboom.it> wrote: >> >> >> >>> Hi, >> >>> >> >>> Commit 63753b3e0dc56efb1acf94fa46f3fee7bc59281c x86: allow >> >>> VCPUOP_register_vcpu_info to work again on PVHVM guests >> >>> >> >>> Leaves HVM guests dangling after shutdown or destroy: >> >>> >> >>> xl list gives: >> >>> (null) 16 0 4 --p--d >> >>> 11.5 >> >>> (null) 17 0 1 --ps-d >> >>> 12.0 >> >>> >> >>> (first was destroyed, second shutdown) >> >>> >> >>> The actual xl and qemu processes are gone, so guest only seem to be >> >>> still registered in the hypervisor. >> >>> >> >>> Another thing this seems to trigger (and that perhaps needs fixing) is >> >>> that a "xl shutdown --all --wait" doesn't wait anymore. >> >>> It returns immediately, probably due to the "nullified" name ? >> >> >> >> Is this only happening with Linux guests? >> > >> > AFAIK this seems to happen with guests that use >> > VCPUOP_register_vcpu_info (I'm seeing the same on FreeBSD). >> >> Are we leaving a reference to a page dangling around somewhere? > > <nods> That is my thinking. George, if you would not mind - could you add > this to the list of bugs for Xen 4.3 I am responsible for. Perhaps you can take this off the list again right away: A brief look at the code shows that unmap_vcpu_info() is being called only for PV guests. Patch below/attached (compile tested only). Jan x86: call unmap_vcpu_info() regardless of guest type This fixes a regression from 63753b3e ("x86: allow VCPUOP_register_vcpu_info to work again on PVHVM guests"). Signed-off-by: Jan Beulich <jbeulich@suse.com> --- a/xen/arch/x86/domain.c +++ b/xen/arch/x86/domain.c @@ -2013,7 +2013,11 @@ int domain_relinquish_resources(struct d /* Drop the in-use references to page-table bases. */ for_each_vcpu ( d, v ) + { vcpu_destroy_pagetables(v); + + unmap_vcpu_info(v); + } if ( !is_hvm_domain(d) ) { @@ -2025,8 +2029,6 @@ int domain_relinquish_resources(struct d * mappings. */ destroy_gdt(v); - - unmap_vcpu_info(v); } if ( d->arch.pv_domain.pirq_eoi_map != NULL ) [-- Attachment #2: x86-unmap-vcpu-info-pvhvm.patch --] [-- Type: text/plain, Size: 867 bytes --] x86: call unmap_vcpu_info() regardless of guest type This fixes a regression from 63753b3e ("x86: allow VCPUOP_register_vcpu_info to work again on PVHVM guests"). Signed-off-by: Jan Beulich <jbeulich@suse.com> --- a/xen/arch/x86/domain.c +++ b/xen/arch/x86/domain.c @@ -2013,7 +2013,11 @@ int domain_relinquish_resources(struct d /* Drop the in-use references to page-table bases. */ for_each_vcpu ( d, v ) + { vcpu_destroy_pagetables(v); + + unmap_vcpu_info(v); + } if ( !is_hvm_domain(d) ) { @@ -2025,8 +2029,6 @@ int domain_relinquish_resources(struct d * mappings. */ destroy_gdt(v); - - unmap_vcpu_info(v); } if ( d->arch.pv_domain.pirq_eoi_map != NULL ) [-- Attachment #3: Type: text/plain, Size: 126 bytes --] _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: xen-unstable: commit commit 63753b3e0dc56efb1acf94fa46f3fee7bc59281c leaves HVM guest dangling after shutdown or destroy. 2013-04-30 14:18 ` Jan Beulich @ 2013-05-01 14:35 ` Sander Eikelenboom 0 siblings, 0 replies; 9+ messages in thread From: Sander Eikelenboom @ 2013-05-01 14:35 UTC (permalink / raw) To: Jan Beulich Cc: George Dunlap, roger.pau, xen-devel@lists.xen.org, Konrad Rzeszutek Wilk Tuesday, April 30, 2013, 4:18:28 PM, you wrote: >>>> On 30.04.13 at 15:55, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> wrote: >> On Wed, Apr 24, 2013 at 10:31:20AM +0100, George Dunlap wrote: >>> On Tue, Apr 23, 2013 at 4:35 PM, Roger Pau Monné <roger.pau@citrix.com> wrote: >>> > On 20/04/13 20:56, Konrad Rzeszutek Wilk wrote: >>> >> >>> >> >>> >> Sander Eikelenboom <linux@eikelenboom.it> wrote: >>> >> >>> >>> Hi, >>> >>> >>> >>> Commit 63753b3e0dc56efb1acf94fa46f3fee7bc59281c x86: allow >>> >>> VCPUOP_register_vcpu_info to work again on PVHVM guests >>> >>> >>> >>> Leaves HVM guests dangling after shutdown or destroy: >>> >>> >>> >>> xl list gives: >>> >>> (null) 16 0 4 --p--d >>> >>> 11.5 >>> >>> (null) 17 0 1 --ps-d >>> >>> 12.0 >>> >>> >>> >>> (first was destroyed, second shutdown) >>> >>> >>> >>> The actual xl and qemu processes are gone, so guest only seem to be >>> >>> still registered in the hypervisor. >>> >>> >>> >>> Another thing this seems to trigger (and that perhaps needs fixing) is >>> >>> that a "xl shutdown --all --wait" doesn't wait anymore. >>> >>> It returns immediately, probably due to the "nullified" name ? >>> >> >>> >> Is this only happening with Linux guests? >>> > >>> > AFAIK this seems to happen with guests that use >>> > VCPUOP_register_vcpu_info (I'm seeing the same on FreeBSD). >>> >>> Are we leaving a reference to a page dangling around somewhere? >> >> <nods> That is my thinking. George, if you would not mind - could you add >> this to the list of bugs for Xen 4.3 I am responsible for. > Perhaps you can take this off the list again right away: A brief look > at the code shows that unmap_vcpu_info() is being called only for > PV guests. Patch below/attached (compile tested only). > Jan Works for me (tm) Thx Sander > x86: call unmap_vcpu_info() regardless of guest type > This fixes a regression from 63753b3e ("x86: allow > VCPUOP_register_vcpu_info to work again on PVHVM guests"). > Signed-off-by: Jan Beulich <jbeulich@suse.com> > --- a/xen/arch/x86/domain.c > +++ b/xen/arch/x86/domain.c > @@ -2013,7 +2013,11 @@ int domain_relinquish_resources(struct d > > /* Drop the in-use references to page-table bases. */ > for_each_vcpu ( d, v ) > + { > vcpu_destroy_pagetables(v); > + > + unmap_vcpu_info(v); > + } > > if ( !is_hvm_domain(d) ) > { > @@ -2025,8 +2029,6 @@ int domain_relinquish_resources(struct d > * mappings. > */ > destroy_gdt(v); > - > - unmap_vcpu_info(v); > } > > if ( d->arch.pv_domain.pirq_eoi_map != NULL ) _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel ^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2013-05-01 14:35 UTC | newest] Thread overview: 9+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2013-04-20 13:21 xen-unstable: commit commit 63753b3e0dc56efb1acf94fa46f3fee7bc59281c leaves HVM guest dangling after shutdown or destroy Sander Eikelenboom 2013-04-20 18:56 ` Konrad Rzeszutek Wilk 2013-04-20 20:32 ` Sander Eikelenboom 2013-04-23 15:35 ` Roger Pau Monné 2013-04-24 9:31 ` George Dunlap 2013-04-30 13:55 ` Konrad Rzeszutek Wilk 2013-04-30 13:58 ` George Dunlap 2013-04-30 14:18 ` Jan Beulich 2013-05-01 14:35 ` Sander Eikelenboom
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.