xen-unstable: commit commit 63753b3e0dc56efb1acf94fa46f3fee7bc59281c leaves HVM guest dangling after shutdown or destroy.

xen-unstable: commit commit 63753b3e0dc56efb1acf94fa46f3fee7bc59281c leaves HVM guest dangling after shutdown or destroy.

[Sander Eikelenboom]

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

Re: xen-unstable: commit commit 63753b3e0dc56efb1acf94fa46f3fee7bc59281c leaves HVM guest dangling after shutdown or destroy.

[Konrad Rzeszutek Wilk]

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.

Re: xen-unstable: commit commit 63753b3e0dc56efb1acf94fa46f3fee7bc59281c leaves HVM guest dangling after shutdown or destroy.

[Sander Eikelenboom]

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

Re: xen-unstable: commit commit 63753b3e0dc56efb1acf94fa46f3fee7bc59281c leaves HVM guest dangling after shutdown or destroy.

[Roger Pau Monné]

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
> 

Re: xen-unstable: commit commit 63753b3e0dc56efb1acf94fa46f3fee7bc59281c leaves HVM guest dangling after shutdown or destroy.

[George Dunlap]

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

Re: xen-unstable: commit commit 63753b3e0dc56efb1acf94fa46f3fee7bc59281c leaves HVM guest dangling after shutdown or destroy.

[Konrad Rzeszutek Wilk]

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.

Re: xen-unstable: commit commit 63753b3e0dc56efb1acf94fa46f3fee7bc59281c leaves HVM guest dangling after shutdown or destroy.

[George Dunlap]

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

Re: xen-unstable: commit commit 63753b3e0dc56efb1acf94fa46f3fee7bc59281c leaves HVM guest dangling after shutdown or destroy.

[Jan Beulich]

[-- 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

Re: xen-unstable: commit commit 63753b3e0dc56efb1acf94fa46f3fee7bc59281c leaves HVM guest dangling after shutdown or destroy.

[Sander Eikelenboom]

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