Re: [Xen-devel] [PATCH 08/10] VMX: disable PML in vmx_vcpu_destroy

[Kai Huang <kai.huang@xxxxxxxxxxxxxxx>]

On 04/09/2015 08:04 PM, Tim Deegan wrote:
> At 10:35 +0800 on 27 Mar (1427452552), Kai Huang wrote:
> > It's possible domain still remains in log-dirty mode when it is about to be
> > destroyed, in which case we should manually disable PML for it.
> >
> > Signed-off-by: Kai Huang <kai.huang@xxxxxxxxxxxxxxx>
> > ---
> >   xen/arch/x86/hvm/vmx/vmx.c | 9 +++++++++
> >   1 file changed, 9 insertions(+)
> >
> > diff --git a/xen/arch/x86/hvm/vmx/vmx.c b/xen/arch/x86/hvm/vmx/vmx.c
> > index fce3aa2..75ac44b 100644
> > --- a/xen/arch/x86/hvm/vmx/vmx.c
> > +++ b/xen/arch/x86/hvm/vmx/vmx.c
> > @@ -153,6 +153,15 @@ static int vmx_vcpu_initialise(struct vcpu *v)
> >   
> >   static void vmx_vcpu_destroy(struct vcpu *v)
> >   {
> > +    /*
> > +     * There are cases that domain still remains in log-dirty mode when it is
> > +     * about to be destroyed (ex, user types 'xl destroy <dom>'), in which case
> > +     * we should disable PML manually here. Note that vmx_vcpu_destroy is 
> > called
> > +     * prior to vmx_domain_destroy so we need to disable PML for each vcpu
> > +     * separately here.
> > +     */
> > +    if ( vmx_vcpu_pml_enabled(v) )
> > +        vmx_vcpu_disable_pml(v);
> Looking at this and other callers of these enable/disable functions, I
> think it would be better to make those functions idempotent (i.e.
> *_{en,dis}able_pml() should just return success if PML is already
> enabled/disabled).  Then you don't need to check in every caller, and
> there's no risk of a crash if one caller is missing the check.
Do you mean something like below?

bool_t vmx_vcpu_enable_pml(struct vcpu *v)
{
    if ( vmx_vcpu_pml_enabled(v) )
        return success;
    ......    /* code to enable */

    return success;
error:
    ...
    return failure;
}

This should be also fine. I will do this. But I think 
vmx_{vcpu|domain}_disable_pml should remain return value of void.
Thanks,
-Kai
> Cheers,
>
> Tim.

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel