All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Roger Pau Monné" <roger.pau@citrix.com>
To: Jan Beulich <jbeulich@suse.com>
Cc: "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	George Dunlap <george.dunlap@citrix.com>,
	Julien Grall <julien@xen.org>,
	Stefano Stabellini <sstabellini@kernel.org>, Wei Liu <wl@xen.org>
Subject: Re: [PATCH v3 7/8] x86: introduce GADDR based secondary time area registration alternative
Date: Wed, 27 Sep 2023 17:50:08 +0200	[thread overview]
Message-ID: <ZRRPMAxlpB03_GMJ@MacBookPdeRoger> (raw)
In-Reply-To: <77218fb0-5e96-4ecb-c2b0-4fe8c3ba683f@suse.com>

On Wed, May 03, 2023 at 05:58:01PM +0200, Jan Beulich wrote:
> The registration by virtual/linear address has downsides: The access is
> expensive for HVM/PVH domains. Furthermore for 64-bit PV domains the area
> is inaccessible (and hence cannot be updated by Xen) when in guest-user
> mode.
> 
> Introduce a new vCPU operation allowing to register the secondary time
> area by guest-physical address.
> 
> An at least theoretical downside to using physically registered areas is
> that PV then won't see dirty (and perhaps also accessed) bits set in its
> respective page table entries.
> 
> Signed-off-by: Jan Beulich <jbeulich@suse.com>

Reviewed-by: Roger Pau Monné <roger.pau@citrix.com>

> ---
> v3: Re-base.
> v2: Forge version in force_update_secondary_system_time().
> 
> --- a/xen/arch/x86/domain.c
> +++ b/xen/arch/x86/domain.c
> @@ -1504,6 +1504,15 @@ int arch_vcpu_reset(struct vcpu *v)
>      return 0;
>  }
>  
> +static void cf_check
> +time_area_populate(void *map, struct vcpu *v)
> +{
> +    if ( is_pv_vcpu(v) )
> +        v->arch.pv.pending_system_time.version = 0;
> +
> +    force_update_secondary_system_time(v, map);
> +}
> +
>  long do_vcpu_op(int cmd, unsigned int vcpuid, XEN_GUEST_HANDLE_PARAM(void) arg)
>  {
>      long rc = 0;
> @@ -1541,6 +1550,25 @@ long do_vcpu_op(int cmd, unsigned int vc
>  
>          break;
>      }
> +
> +    case VCPUOP_register_vcpu_time_phys_area:
> +    {
> +        struct vcpu_register_time_memory_area area;
> +
> +        rc = -EFAULT;
> +        if ( copy_from_guest(&area.addr.p, arg, 1) )
> +            break;
> +
> +        rc = map_guest_area(v, area.addr.p,
> +                            sizeof(vcpu_time_info_t),
> +                            &v->arch.time_guest_area,
> +                            time_area_populate);
> +        if ( rc == -ERESTART )
> +            rc = hypercall_create_continuation(__HYPERVISOR_vcpu_op, "iih",
> +                                               cmd, vcpuid, arg);
> +
> +        break;
> +    }
>  
>      case VCPUOP_get_physid:
>      {
> --- a/xen/arch/x86/include/asm/domain.h
> +++ b/xen/arch/x86/include/asm/domain.h
> @@ -692,6 +692,8 @@ void domain_cpu_policy_changed(struct do
>  
>  bool update_secondary_system_time(struct vcpu *,
>                                    struct vcpu_time_info *);
> +void force_update_secondary_system_time(struct vcpu *,
> +                                        struct vcpu_time_info *);
>  
>  void vcpu_show_registers(const struct vcpu *);
>  
> --- a/xen/arch/x86/time.c
> +++ b/xen/arch/x86/time.c
> @@ -1633,6 +1633,16 @@ void force_update_vcpu_system_time(struc
>      __update_vcpu_system_time(v, 1);
>  }
>  
> +void force_update_secondary_system_time(struct vcpu *v,
> +                                        struct vcpu_time_info *map)
> +{
> +    struct vcpu_time_info u;
> +
> +    collect_time_info(v, &u);
> +    u.version = -1; /* Compensate for version_update_end(). */

Hm, we do not seem to compensate in
VCPUOP_register_vcpu_time_memory_area, what's more, in that case the
initial version is picked from the contents of the guest address.
Hopefully the guest will have zeroed the memory.

FWIW, I would be fine with leaving this at 0, so the first version
guest sees is 1.

Thanks, Roger.


  reply	other threads:[~2023-09-27 15:50 UTC|newest]

Thread overview: 38+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-05-03 15:53 [PATCH v3 0/8] runstate/time area registration by (guest) physical address Jan Beulich
2023-05-03 15:54 ` [PATCH v3 1/8] domain: GADDR based shared guest area registration alternative - teardown Jan Beulich
2023-09-27  8:51   ` Roger Pau Monné
2023-09-27  9:55     ` Jan Beulich
2023-09-27 10:42       ` Roger Pau Monné
2023-09-27 10:46         ` Jan Beulich
2023-09-27 10:50           ` Roger Pau Monné
2023-09-27 11:44             ` Jan Beulich
2023-05-03 15:55 ` [PATCH v3 2/8] domain: update GADDR based runstate guest area Jan Beulich
2023-09-27  9:44   ` Roger Pau Monné
2023-09-27 10:19     ` Jan Beulich
2023-05-03 15:55 ` [PATCH v3 3/8] x86: update GADDR based secondary time area Jan Beulich
2023-09-27 10:14   ` Roger Pau Monné
2023-05-03 15:56 ` [PATCH v3 4/8] x86/mem-sharing: copy GADDR based shared guest areas Jan Beulich
2023-05-03 17:14   ` Tamas K Lengyel
2023-05-04  7:44     ` Jan Beulich
2023-05-04 12:50       ` Tamas K Lengyel
2023-05-04 14:25         ` Jan Beulich
2023-09-27 11:08   ` Roger Pau Monné
2023-09-27 12:06     ` Jan Beulich
2023-09-27 14:05       ` Roger Pau Monné
2023-09-27 15:11         ` Jan Beulich
     [not found]     ` <CABfawhkn1xXA+qEjB4-HtOVUZHONDE6ngMJZPe3fSPtoAtmg+Q@mail.gmail.com>
2023-09-27 13:54       ` Roger Pau Monné
2023-05-03 15:57 ` [PATCH v3 5/8] domain: map/unmap " Jan Beulich
2023-09-27 14:53   ` Roger Pau Monné
2023-09-27 15:29     ` Jan Beulich
2023-05-03 15:57 ` [PATCH v3 6/8] domain: introduce GADDR based runstate area registration alternative Jan Beulich
2023-09-27 15:24   ` Roger Pau Monné
2023-09-27 15:36     ` Jan Beulich
2023-05-03 15:58 ` [PATCH v3 7/8] x86: introduce GADDR based secondary time " Jan Beulich
2023-09-27 15:50   ` Roger Pau Monné [this message]
2023-09-27 16:12     ` Jan Beulich
2023-05-03 15:58 ` [PATCH v3 8/8] common: convert vCPU info area registration Jan Beulich
2023-09-28  8:24   ` Roger Pau Monné
2023-09-28  9:53     ` Jan Beulich
2023-09-28 10:15       ` Roger Pau Monné
2023-09-28 10:35         ` Jan Beulich
2023-09-28 11:24           ` Roger Pau Monné

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=ZRRPMAxlpB03_GMJ@MacBookPdeRoger \
    --to=roger.pau@citrix.com \
    --cc=andrew.cooper3@citrix.com \
    --cc=george.dunlap@citrix.com \
    --cc=jbeulich@suse.com \
    --cc=julien@xen.org \
    --cc=sstabellini@kernel.org \
    --cc=wl@xen.org \
    --cc=xen-devel@lists.xenproject.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.