All of lore.kernel.org
 help / color / mirror / Atom feed
From: Keir Fraser <keir.xen@gmail.com>
To: Jan Beulich <JBeulich@suse.com>, xen-devel <xen-devel@lists.xen.org>
Cc: George Dunlap <George.Dunlap@eu.citrix.com>,
	Tim Deegan <tim@xen.org>, Ian Campbell <ian.campbell@citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [PATCH] x86: re-enable VCPUOP_register_vcpu_time_memory_area
Date: Thu, 16 May 2013 10:44:10 +0100	[thread overview]
Message-ID: <CDBA68FA.251C6%keir.xen@gmail.com> (raw)
In-Reply-To: <5194B93702000078000D6A7E@nat28.tlf.novell.com>

On 16/05/2013 09:47, "Jan Beulich" <JBeulich@suse.com> wrote:

> By moving the call to update_vcpu_system_time() out of schedule() into
> arch-specific context switch code, the original problem of the function
> accessing the wrong domain's address space goes away (obvious even from
> patch context, as update_runstate_area() does similar copying).
> 
> Signed-off-by: Jan Beulich <jbeulich@suse.com>

Acked-by: Keir Fraser <keir@xen.org>

> ---
> Regardless of the code freeze I'd still like to propose this for
> inclusion in 4.3, mainly based on the fact that this got disabled late
> in the 4.0 release cycle with the expectation that it would get
> re-enabled soon after. Now that upstream Linux also has, as of 3.8 at
> least on x86-64, the necessary hypervisor independent support code, it
> would be odd to not leverage this on Xen.
> 
> --- a/xen/arch/arm/domain.c
> +++ b/xen/arch/arm/domain.c
> @@ -232,6 +232,9 @@ static void schedule_tail(struct vcpu *p
>  
>      if ( prev != current )
>          update_runstate_area(current);
> +
> +    /* Ensure that the vcpu has an up-to-date time base. */
> +    update_vcpu_system_time(current);
>  }
>  
>  static void continue_new_vcpu(struct vcpu *prev)
> --- a/xen/arch/x86/domain.c
> +++ b/xen/arch/x86/domain.c
> @@ -966,11 +966,6 @@ arch_do_vcpu_op(
>  
>      switch ( cmd )
>      {
> -    /*
> -     * XXX Disable for 4.0.0: __update_vcpu_system_time() writes to the given
> -     * virtual address even when running in another domain's address space.
> -     */
> -#if 0
>      case VCPUOP_register_vcpu_time_memory_area:
>      {
>          struct vcpu_register_time_memory_area area;
> @@ -989,7 +984,6 @@ arch_do_vcpu_op(
>  
>          break;
>      }
> -#endif
>  
>      case VCPUOP_get_physid:
>      {
> @@ -1457,6 +1451,9 @@ void context_switch(struct vcpu *prev, s
>      if (prev != next)
>          update_runstate_area(next);
>  
> +    /* Ensure that the vcpu has an up-to-date time base. */
> +    update_vcpu_system_time(next);
> +
>      schedule_tail(next);
>      BUG();
>  }
> --- a/xen/arch/x86/hvm/hvm.c
> +++ b/xen/arch/x86/hvm/hvm.c
> @@ -3174,6 +3174,7 @@ static long hvm_vcpu_op(
>      case VCPUOP_set_singleshot_timer:
>      case VCPUOP_stop_singleshot_timer:
>      case VCPUOP_register_vcpu_info:
> +    case VCPUOP_register_vcpu_time_memory_area:
>          rc = do_vcpu_op(cmd, vcpuid, arg);
>          break;
>      default:
> @@ -3232,6 +3233,7 @@ static long hvm_vcpu_op_compat32(
>      case VCPUOP_set_singleshot_timer:
>      case VCPUOP_stop_singleshot_timer:
>      case VCPUOP_register_vcpu_info:
> +    case VCPUOP_register_vcpu_time_memory_area:
>          rc = compat_vcpu_op(cmd, vcpuid, arg);
>          break;
>      default:
> --- a/xen/common/schedule.c
> +++ b/xen/common/schedule.c
> @@ -1231,8 +1231,6 @@ static void schedule(void)
>      if ( next_slice.migrated )
>          evtchn_move_pirqs(next);
>  
> -    /* Ensure that the domain has an up-to-date time base. */
> -    update_vcpu_system_time(next);
>      vcpu_periodic_timer_work(next);
>  
>      context_switch(prev, next);
> 
> 
> 

  reply	other threads:[~2013-05-16  9:44 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-05-16  8:47 [PATCH] x86: re-enable VCPUOP_register_vcpu_time_memory_area Jan Beulich
2013-05-16  9:44 ` Keir Fraser [this message]
2013-05-21  8:21   ` Jan Beulich
2013-05-16 14:40 ` Ian Campbell
2013-05-16 15:01   ` Jan Beulich
2013-05-16 16:15     ` Matt Wilson
2013-05-17  6:28       ` Jan Beulich
2013-05-17  8:13       ` Ian Campbell

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=CDBA68FA.251C6%keir.xen@gmail.com \
    --to=keir.xen@gmail.com \
    --cc=George.Dunlap@eu.citrix.com \
    --cc=JBeulich@suse.com \
    --cc=ian.campbell@citrix.com \
    --cc=stefano.stabellini@eu.citrix.com \
    --cc=tim@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.