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

[Sander Eikelenboom <linux@xxxxxxxxxxxxxx>]

Tuesday, April 30, 2013, 4:18:28 PM, you wrote:

>>>> On 30.04.13 at 15:55, Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx> 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@xxxxxxxxxx> 
>>> wrote:
>>> > On 20/04/13 20:56, Konrad Rzeszutek Wilk wrote:
>>> >>
>>> >>
>>> >> Sander Eikelenboom <linux@xxxxxxxxxxxxxx> 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@xxxxxxxx>

> --- 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@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel