From: Jan Beulich <jbeulich@suse.com>
To: Tamas K Lengyel <tamas@tklengyel.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>, "Roger Pau Monné" <roger.pau@citrix.com>
Subject: Re: [PATCH v2 4/8] x86/mem-sharing: copy GADDR based shared guest areas
Date: Mon, 23 Jan 2023 17:24:29 +0100 [thread overview]
Message-ID: <a92b9714-5e29-146f-3b68-b44692c56de1@suse.com> (raw)
In-Reply-To: <CABfawhmTe3Rxwo54gR5-4KGv=K0Ai7o9g6i=1nkb=XdES1CrcQ@mail.gmail.com>
On 23.01.2023 17:09, Tamas K Lengyel wrote:
> On Mon, Jan 23, 2023 at 9:55 AM Jan Beulich <jbeulich@suse.com> wrote:
>> --- a/xen/arch/x86/mm/mem_sharing.c
>> +++ b/xen/arch/x86/mm/mem_sharing.c
>> @@ -1653,6 +1653,65 @@ 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;
>> +
>> + /*
>> + * Simply specify the entire range up to the end of the page.
> All the
>> + * function uses it for is a check for not crossing page
> boundaries.
>> + */
>> + 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);
>
> Everything to this point seems to be non mem-sharing/forking related. Could
> these live somewhere else? There must be some other place where allocating
> these areas happens already for non-fork VMs so it would make sense to just
> refactor that code to be callable from here.
It is the "copy" aspect with makes this mem-sharing (or really fork)
specific. Plus in the end this is no different from what you have
there right now for copying the vCPU info area. In the final patch
that other code gets removed by re-using the code here.
I also haven't been able to spot anything that could be factored
out (and one might expect that if there was something, then the vCPU
info area copying should also already have used it). map_guest_area()
is all that is used for other purposes as well.
>> +
>> + 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);
>> @@ -1745,6 +1804,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;
>> @@ -1987,7 +2056,10 @@ int mem_sharing_fork_reset(struct domain
>>
>> state:
>> if ( reset_state )
>> + {
>> rc = copy_settings(d, pd);
>> + /* TBD: What to do here with -ERESTART? */
>
> Where does ERESTART coming from?
From map_guest_area()'s attempt to acquire the hypercall deadlock mutex,
in order to then pause the subject vCPU. I suppose that in the forking
case it may already be paused, but then there's no way map_guest_area()
could know. Looking at the pause count is fragile, as there's no
guarantee that the vCPU may be unpaused while we're still doing work on
it. Hence I view such checks as only suitable for assertions.
Jan
next prev parent reply other threads:[~2023-01-23 16:24 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-01-23 14:51 [PATCH v2 0/8] runstate/time area registration by (guest) physical address Jan Beulich
2023-01-23 14:53 ` [PATCH RFC v2 1/8] domain: GADDR based shared guest area registration alternative - teardown Jan Beulich
2023-01-23 14:53 ` [PATCH RFC v2 2/8] domain: update GADDR based runstate guest area Jan Beulich
2023-01-23 14:54 ` [PATCH v2 3/8] x86: update GADDR based secondary time area Jan Beulich
2023-01-23 14:55 ` [PATCH v2 4/8] x86/mem-sharing: copy GADDR based shared guest areas Jan Beulich
2023-01-23 16:09 ` Tamas K Lengyel
2023-01-23 16:24 ` Jan Beulich [this message]
2023-01-23 18:32 ` Tamas K Lengyel
2023-01-24 11:19 ` Jan Beulich
2023-01-25 15:34 ` Tamas K Lengyel
2023-01-26 8:13 ` Jan Beulich
2023-01-26 15:41 ` Tamas K Lengyel
2023-01-26 16:48 ` Jan Beulich
2023-01-26 17:24 ` Tamas K Lengyel
2023-01-23 14:55 ` [PATCH v2 5/8] domain: map/unmap " Jan Beulich
2023-01-23 14:56 ` [PATCH v2 6/8] domain: introduce GADDR based runstate area registration alternative Jan Beulich
2023-01-23 14:56 ` [PATCH v2 7/8] x86: introduce GADDR based secondary time " Jan Beulich
2023-01-23 14:57 ` [PATCH v2 8/8] 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=a92b9714-5e29-146f-3b68-b44692c56de1@suse.com \
--to=jbeulich@suse.com \
--cc=andrew.cooper3@citrix.com \
--cc=george.dunlap@citrix.com \
--cc=julien@xen.org \
--cc=roger.pau@citrix.com \
--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.