All of lore.kernel.org
 help / color / mirror / Atom feed
From: Hongyang Yang <yanghy@cn.fujitsu.com>
To: Andrew Cooper <andrew.cooper3@citrix.com>,
	Xen-devel <xen-devel@lists.xen.org>
Cc: Keir Fraser <keir@xen.org>, Jan Beulich <JBeulich@suse.com>
Subject: Re: [PATCH v2 1/6] xen/hvm: Permit HVM_PARAM_IDENT_PT to be set more than once
Date: Mon, 11 May 2015 15:51:45 +0800	[thread overview]
Message-ID: <55505F91.3050309@cn.fujitsu.com> (raw)
In-Reply-To: <1431119675-23847-2-git-send-email-andrew.cooper3@citrix.com>

I've reviewed all of the series, looks good to me in general, I will rebase my
patches on top of this series. Would you like me to take this series and send
it together with mine?

On 05/09/2015 05:14 AM, Andrew Cooper wrote:
> There is no conceptual problem with setting this parameter more than once.
> Checkpointed migration streams will typically set it once per checkpoint to
> the same value.
>
> The parameter is only actually needed on early-generation VT-x which lacked
> the unrestricted guest capability, although it could plausibly be used on
> newer VT-x with unusual execution control settings.  Short circuit the
> expensive operations on non VT-x hardware.
>
> The parameter itself must always be latched to avoid issues if the VM
> eventually migrates to a host which needs to use the pagetable.
>
> Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
> CC: Keir Fraser <keir@xen.org>
> CC: Jan Beulich <JBeulich@suse.com>
> CC: Yang Hongyang <yanghy@cn.fujitsu.com>
>
> ---
> v2: Don't expose new value prematurely to VT-x
> ---
>   xen/arch/x86/hvm/hvm.c |   14 ++++++++------
>   1 file changed, 8 insertions(+), 6 deletions(-)
>
> diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
> index 8140a27..85dfa52 100644
> --- a/xen/arch/x86/hvm/hvm.c
> +++ b/xen/arch/x86/hvm/hvm.c
> @@ -5730,13 +5730,15 @@ static int hvmop_set_param(
>               rc = -EINVAL;
>           break;
>       case HVM_PARAM_IDENT_PT:
> -        rc = -EINVAL;
> -        if ( d->arch.hvm_domain.params[a.index] != 0 )
> -            break;
> -
> -        rc = 0;
> -        if ( !paging_mode_hap(d) )
> +        /*
> +         * Only actually required for VT-x lacking unrestricted_guest
> +         * capabilities.  Short circuit the pause if possible.
> +         */
> +        if ( !paging_mode_hap(d) || !cpu_has_vmx )
> +        {
> +            d->arch.hvm_domain.params[a.index] = a.value;
>               break;
> +        }
>
>           /*
>            * Update GUEST_CR3 in each VMCS to point at identity map.
>

-- 
Thanks,
Yang.

  reply	other threads:[~2015-05-11  7:51 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-05-08 21:14 [PATCH v2 0/6] Misc patches to aid migration v2 Remus support Andrew Cooper
2015-05-08 21:14 ` [PATCH v2 1/6] xen/hvm: Permit HVM_PARAM_IDENT_PT to be set more than once Andrew Cooper
2015-05-11  7:51   ` Hongyang Yang [this message]
2015-05-11  8:00     ` Andrew Cooper
2015-05-11  8:06       ` Hongyang Yang
2015-05-08 21:14 ` [PATCH v2 2/6] libxc/restore: Bail if unknown options are found Andrew Cooper
2015-05-11  9:23   ` David Vrabel
2015-05-11 10:44     ` David Vrabel
2015-05-11 10:43   ` David Vrabel
2015-05-08 21:14 ` [PATCH v2 3/6] libxc/migration: Be rather stricter with illformed callers Andrew Cooper
2015-05-11 11:33   ` Ian Campbell
2015-05-11 11:47     ` Andrew Cooper
2015-05-11 11:57       ` Ian Campbell
2015-05-08 21:14 ` [PATCH v2 4/6] libxc/save: Adjust stream-position callbacks for checkpointed streams Andrew Cooper
2015-05-11 11:36   ` Ian Campbell
2015-05-11 11:56     ` Andrew Cooper
2015-05-11 12:05       ` Ian Campbell
2015-05-11 12:06         ` Andrew Cooper
2015-05-08 21:14 ` [PATCH v2 5/6] tools/migration: Specification update for 'checkpointed' flag Andrew Cooper
2015-05-08 21:14 ` [PATCH v2 6/6] libxc/migration: Specification update for CHECKPOINT records Andrew Cooper

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=55505F91.3050309@cn.fujitsu.com \
    --to=yanghy@cn.fujitsu.com \
    --cc=JBeulich@suse.com \
    --cc=andrew.cooper3@citrix.com \
    --cc=keir@xen.org \
    --cc=xen-devel@lists.xen.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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.