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>,
	Tamas K Lengyel <tamas@tklengyel.com>
Subject: Re: [PATCH v3 4/8] x86/mem-sharing: copy GADDR based shared guest areas
Date: Wed, 27 Sep 2023 13:08:15 +0200	[thread overview]
Message-ID: <ZRQNHyggOFD1FuMD@MacBookPdeRoger> (raw)
In-Reply-To: <a79d2a8b-6d6e-bd31-b079-a30b555e5fd0@suse.com>

On Wed, May 03, 2023 at 05:56:46PM +0200, Jan Beulich wrote:
> In preparation of the introduction of new vCPU operations allowing to
> register the respective areas (one of the two is x86-specific) by
> guest-physical address, add the necessary fork handling (with the
> backing function yet to be filled in).
> 
> Signed-off-by: Jan Beulich <jbeulich@suse.com>

Given the very limited and specific usage of the current Xen forking
code, do we really need to bother about copying such areas?

IOW: I doubt that not updating the runstate/time areas will make any
difference to the forking code ATM.

> ---
> v3: Extend comment.
> 
> --- a/xen/arch/x86/mm/mem_sharing.c
> +++ b/xen/arch/x86/mm/mem_sharing.c
> @@ -1641,6 +1641,68 @@ static void copy_vcpu_nonreg_state(struc
>      hvm_set_nonreg_state(cd_vcpu, &nrs);
>  }
>  
> +static int copy_guest_area(struct guest_area *cd_area,
> +                           const struct guest_area *d_area,
> +                           struct vcpu *cd_vcpu,
> +                           const struct domain *d)
> +{
> +    mfn_t d_mfn, cd_mfn;
> +
> +    if ( !d_area->pg )
> +        return 0;
> +
> +    d_mfn = page_to_mfn(d_area->pg);
> +
> +    /* Allocate & map a page for the area if it hasn't been already. */
> +    if ( !cd_area->pg )
> +    {
> +        gfn_t gfn = mfn_to_gfn(d, d_mfn);
> +        struct p2m_domain *p2m = p2m_get_hostp2m(cd_vcpu->domain);
> +        p2m_type_t p2mt;
> +        p2m_access_t p2ma;
> +        unsigned int offset;
> +        int ret;
> +
> +        cd_mfn = p2m->get_entry(p2m, gfn, &p2mt, &p2ma, 0, NULL, NULL);
> +        if ( mfn_eq(cd_mfn, INVALID_MFN) )
> +        {
> +            struct page_info *pg = alloc_domheap_page(cd_vcpu->domain, 0);
> +
> +            if ( !pg )
> +                return -ENOMEM;
> +
> +            cd_mfn = page_to_mfn(pg);
> +            set_gpfn_from_mfn(mfn_x(cd_mfn), gfn_x(gfn));
> +
> +            ret = p2m->set_entry(p2m, gfn, cd_mfn, PAGE_ORDER_4K, p2m_ram_rw,
> +                                 p2m->default_access, -1);
> +            if ( ret )
> +                return ret;
> +        }
> +        else if ( p2mt != p2m_ram_rw )
> +            return -EBUSY;

Shouldn't the populate of the underlying gfn in the fork case
be done by map_guest_area itself?

What if a forked guest attempts to register a new runstate/time info
against an address not yet populated?

> +        /*
> +         * Map the into the guest. For simplicity specify the entire range up
> +         * to the end of the page: All the function uses it for is to check
> +         * that the range doesn't cross page boundaries. Having the area mapped
> +         * in the original domain implies that it fits there and therefore will
> +         * also fit in the clone.
> +         */
> +        offset = PAGE_OFFSET(d_area->map);
> +        ret = map_guest_area(cd_vcpu, gfn_to_gaddr(gfn) + offset,
> +                             PAGE_SIZE - offset, cd_area, NULL);
> +        if ( ret )
> +            return ret;
> +    }
> +    else
> +        cd_mfn = page_to_mfn(cd_area->pg);
> +
> +    copy_domain_page(cd_mfn, d_mfn);
> +
> +    return 0;
> +}
> +
>  static int copy_vpmu(struct vcpu *d_vcpu, struct vcpu *cd_vcpu)
>  {
>      struct vpmu_struct *d_vpmu = vcpu_vpmu(d_vcpu);
> @@ -1733,6 +1795,16 @@ static int copy_vcpu_settings(struct dom
>              copy_domain_page(new_vcpu_info_mfn, vcpu_info_mfn);
>          }
>  
> +        /* Same for the (physically registered) runstate and time info areas. */
> +        ret = copy_guest_area(&cd_vcpu->runstate_guest_area,
> +                              &d_vcpu->runstate_guest_area, cd_vcpu, d);
> +        if ( ret )
> +            return ret;
> +        ret = copy_guest_area(&cd_vcpu->arch.time_guest_area,
> +                              &d_vcpu->arch.time_guest_area, cd_vcpu, d);
> +        if ( ret )
> +            return ret;
> +
>          ret = copy_vpmu(d_vcpu, cd_vcpu);
>          if ( ret )
>              return ret;
> @@ -1974,7 +2046,10 @@ int mem_sharing_fork_reset(struct domain
>  
>   state:
>      if ( reset_state )
> +    {
>          rc = copy_settings(d, pd);
> +        /* TBD: What to do here with -ERESTART? */
> +    }
>  
>      domain_unpause(d);
>  
> --- a/xen/common/domain.c
> +++ b/xen/common/domain.c
> @@ -1572,6 +1572,13 @@ void unmap_vcpu_info(struct vcpu *v)
>      put_page_and_type(mfn_to_page(mfn));
>  }
>  
> +int map_guest_area(struct vcpu *v, paddr_t gaddr, unsigned int size,
> +                   struct guest_area *area,
> +                   void (*populate)(void *dst, struct vcpu *v))

Oh, the prototype for this is added in patch 1, almost missed it.

Why not also add this dummy implementation in patch 1 then?

Thanks, Roger.


  parent reply	other threads:[~2023-09-27 11:08 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é [this message]
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é
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=ZRQNHyggOFD1FuMD@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=tamas@tklengyel.com \
    --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.