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

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

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.

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

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
>

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

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.

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

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