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>,
	Henry Wang <Henry.Wang@arm.com>,
	Tamas K Lengyel <tamas@tklengyel.com>
Subject: Re: [PATCH v4 5/9] x86/mem-sharing: copy GADDR based shared guest areas
Date: Thu, 28 Sep 2023 11:51:01 +0200	[thread overview]
Message-ID: <ZRVMhdyI8s4chr7b@MacBookPdeRoger> (raw)
In-Reply-To: <6047c192-0f37-e4ff-5980-fd137b3f1869@suse.com>

On Thu, Sep 28, 2023 at 09:16:20AM +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>
> ---
> 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;
> +        }

I'm still unsure why map_guest_area() shouldn't be able to deal with a
forked child needing the page to be mapped.  What happens when a
forked child executes the hypercall to map such areas against not yet
populated gfns?

Shouldn't map_guest_area() be capable of handling those calls and
populating on demand?

> +        else if ( p2mt != p2m_ram_rw )
> +            return -EBUSY;
> +
> +        /*
> +         * Map the area 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);

I think the page copy should be done only once, when the page is
populated on the child p2m.  Otherwise areas smaller than a page size
(like vpcu_time_info_t) that share the same page will get multiple
copies of the same data for no reason.

Thanks, Roger.


  reply	other threads:[~2023-09-28  9:52 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-09-28  6:59 [PATCH v4 0/9] runstate/time area registration by (guest) physical address Jan Beulich
2023-09-28  7:01 ` [PATCH v4 1/9] x86/shim: zap runstate and time area handles during shutdown Jan Beulich
2023-09-28  9:27   ` Roger Pau Monné
2023-09-28  7:14 ` [PATCH v4 2/9] domain: GADDR based shared guest area registration alternative - teardown Jan Beulich
2023-09-28  7:15 ` [PATCH v4 3/9] domain: update GADDR based runstate guest area Jan Beulich
2023-09-28 12:15   ` Julien Grall
2023-09-28  7:15 ` [PATCH v4 4/9] x86: update GADDR based secondary time area Jan Beulich
2023-09-28  7:16 ` [PATCH v4 5/9] x86/mem-sharing: copy GADDR based shared guest areas Jan Beulich
2023-09-28  9:51   ` Roger Pau Monné [this message]
2023-09-28 10:11     ` Jan Beulich
2023-09-28 11:07       ` Roger Pau Monné
     [not found]         ` <CABfawhmAZGTaKZfmwY4t8599i6qKaTOJ-fngFmtvS4LhJMh7iA@mail.gmail.com>
2023-09-28 13:19           ` Jan Beulich
     [not found]             ` <CABfawhkK7LVQKhTtCAMpoaGLH24SwpyEAJGpu-PohR5e6W=pMw@mail.gmail.com>
2023-10-16  9:50               ` Jan Beulich
2023-09-28 14:08           ` Roger Pau Monné
     [not found]             ` <CABfawhmfFuB14CiPdyaP4HNayms0AG5=4h1FNURu4MDgt2HzAg@mail.gmail.com>
2023-09-29 14:17               ` Roger Pau Monné
2023-09-28  7:16 ` [PATCH v4 6/9] domain: map/unmap " Jan Beulich
2023-09-28 10:04   ` Roger Pau Monné
2023-09-28 10:14     ` Jan Beulich
2023-09-28 11:10       ` Roger Pau Monné
2023-09-28  7:17 ` [PATCH v4 7/9] domain: introduce GADDR based runstate area registration alternative Jan Beulich
2023-09-28  7:17 ` [PATCH v4 8/9] x86: introduce GADDR based secondary time " Jan Beulich
2023-09-28  7:18 ` [PATCH v4 9/9] common: convert vCPU info area registration Jan Beulich

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=ZRVMhdyI8s4chr7b@MacBookPdeRoger \
    --to=roger.pau@citrix.com \
    --cc=Henry.Wang@arm.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.