[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH v5 06/10] x86/mem-sharing: copy GADDR based shared guest areas


  • To: Julien Grall <julien@xxxxxxx>
  • From: Roger Pau Monné <roger.pau@xxxxxxxxxx>
  • Date: Wed, 4 Oct 2023 15:00:31 +0200
  • Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=citrix.com; dmarc=pass action=none header.from=citrix.com; dkim=pass header.d=citrix.com; arc=none
  • Arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=FSqgwmQYedfnEbTVWUs6QNI2Y97dUEO6Y+dZg3TTgd8=; b=A7cbH71QlJEPwBlwwJv4A/cK2/99OtLge9BIeOGki9VJ/1BR3eDbzG/LdN02uAllQHF/w1b1J8hmeyZ1KqwsB/kuct9mUJ89ZuQmEQepXlEcS5FpgTpYtBg2qxjsQlfFveekXboX7fKkJzO6nqHMx19K0TMr/6FuDb+h20PvgcEhw0asC07UGIIpqriSBv8b2UaRmhN8OcVPJU1fRxdEpnoiXuzCWQp5ULLRYIWEi5WmfjcG+82bxeP0EvogvT1d68da1pATgrdVU8pfqDH/83o3xWAsUubSQQyXgLva8I9piwCOfVo/5W1q45olStQi78o8YaDenDbIyfX1CBTtKA==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=jUgPHPVWy7R+31WWycQSU7hOTw9TinG/e5jKH1lE+pMB9H3yjImSF68Kvr1GPrIwWuJhLiKZPHDl/jRbkHRWvLVOafGXJpavFTreJcBCS/6sYfU0tN2fWOCmxm6Jgc7u2KHPXTVRSxRF004TuttI4y8Gk4XjWWuvzDY1XA7IpwWHDdyh3vp6yMd1iSz6McC+NPJPbGo1pT//Rv9K5PN58FUUxsK81gsUL1oyf2KvlEdW+1stDF+Uy07x/qGCxeqcprgDJGWxE0HJasZFCvdJqI9vPog9/lIMpsIR/MFua5whTTWrPoWmaJMetGjijtDdM7P/fKDu+06ScOuJ26h6yw==
  • Authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=citrix.com;
  • Cc: Tamas K Lengyel <tamas@xxxxxxxxxxxxx>, xen-devel@xxxxxxxxxxxxxxxxxxxx, henry.wang@xxxxxxx, Jan Beulich <jbeulich@xxxxxxxx>, Andrew Cooper <andrew.cooper3@xxxxxxxxxx>, George Dunlap <george.dunlap@xxxxxxxxxx>, Wei Liu <wl@xxxxxxx>, Stefano Stabellini <sstabellini@xxxxxxxxxx>
  • Delivery-date: Wed, 04 Oct 2023 13:01:01 +0000
  • Ironport-data: A9a23:lJU8fKv58bAwAOyU9HDuirJquufnVKZfMUV32f8akzHdYApBsoF/q tZmKWnXOvnZNDD3fYgna9/npEkCscCBnN5hGlc6rC5jFH4T+JbJXdiXEBz9bniYRiHhoOCLz O1FM4Wdc5pkJpP4jk3wWlQ0hSAkjclkfpKlVaicfHg3HFc4IMsYoUoLs/YjhYJ1isSODQqIu Nfjy+XSI1bg0DNvWo4uw/vrRChH4rKq41v0gnRkPaoQ5QeGyyFOZH4iDfrZw0XQE9E88tGSH 44v/JnhlkvF8hEkDM+Sk7qTWiXmlZaLYGBiIlIPM0STqkAqSh4ai87XB9JFAatjsB2bnsgZ9 Tl4ncfYpTHFnEH7sL91vxFwS0mSNEDdkVPNCSDXXce7lyUqf5ZwqhnH4Y5f0YAwo45K7W9yG fMwAmk2MBCC2/yK27P4Fu9ivpsyPu63M9ZK0p1g5Wmx4fcOZ7nmGv2PyfoGmTA6i4ZJAOrUY NcfZXx3dhPcbhZTO1ARTpUjgOOvgXq5eDpdwL6XjfNvvy6Pk0osgP60aIq9lt+iHK25mm6Co W3L5SLhCwwyP92D0zuVtHmrg4cjmAuiAt9KTuDpr6MCbFu72k4WAhwQX1+Cpt6UqW+fad98E Rcb5X97xUQ13AnxJjXnZDW6vXqFsxg0S9dWVeog52ml1qPR6h2xGmsAQzhOedEi8sQxQFQCx lKP2t/kGzFrmLmUUm6GsKeZqyuoPioYJnNEYjULJSMF7t/5sccshxTAZt95Fei+ididMTP6z i2OrSM+r64OlsNN3KK+lXjYhxq8q56PSRQ6ji3MRX6s5A59YI+jZqSr5ELd4PIGK5yWJmRtp 1ABksmaqewLU5eEkXXVRP1XRen5ofGYLDfbnFhjWYE78Cig8GKieoYW5yxiIEBuMYAPfjqBj FLvhD69LaR7ZBOCBZKbqartVazGEYCI+QzZa83p
  • Ironport-hdrordr: A9a23:XM2N2qMVnfRVG8BcThKjsMiBIKoaSvp037BL7TETdfUxSKelfq +V8cjzuSWZtN9pYgBepTniAsm9qBHnm6KdurNhX4tKNTOO0AGVxepZjLcKrQeOJ8T1zJ846U 9GG5IObqyIfCAK9vrS0U2aN94hxdWdmZrY+Ns2t00dNz2DtclbnmBE4j7yKDwLeODsP+tGKH PZ3Lsjmwad
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>

On Wed, Oct 04, 2023 at 12:01:21PM +0100, Julien Grall wrote:
> Hi Roger,
> 
> On 04/10/2023 09:20, Roger Pau Monné wrote:
> > On Tue, Oct 03, 2023 at 04:25:58PM -0400, Tamas K Lengyel wrote:
> > > On Tue, Oct 3, 2023 at 11:07 AM Julien Grall <julien@xxxxxxx> wrote:
> > > > 
> > > > Hi Roger,
> > > > 
> > > > On 03/10/2023 15:29, Roger Pau Monné wrote:
> > > > > On Tue, Oct 03, 2023 at 09:53:11AM -0400, Tamas K Lengyel wrote:
> > > > 
> > > > Tamas, somehow your e-mails don't show up in my inbox (even if I am
> > > > CCed) or even on lore.kernel.org/xen-devel. It is not even in my SPAM
> > > > folder.
> > > 
> > > Thanks, I've switched mailservers, hopefully that resolves the issue.
> 
> It did. Thanks!
> 
> > > 
> > > > 
> > > > > > On Mon, Oct 2, 2023 at 11:13 AM Roger Pau Monne 
> > > > > > <roger.pau@xxxxxxxxxx> wrote:
> > > > > > > 
> > > > > > > From: Jan Beulich <jbeulich@xxxxxxxx>
> > > > > > > 
> > > > > > > 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@xxxxxxxx>
> > > > > > > Signed-off-by: Roger Pau Monné <roger.pau@xxxxxxxxxx>
> > > > > > > ---
> > > > > > > Changes since v4:
> > > > > > >    - Rely on map_guest_area() to populate the child p2m if 
> > > > > > > necessary.
> > > > > > > ---
> > > > > > >    xen/arch/x86/mm/mem_sharing.c | 31 
> > > > > > > +++++++++++++++++++++++++++++++
> > > > > > >    xen/common/domain.c           |  7 +++++++
> > > > > > >    2 files changed, 38 insertions(+)
> > > > > > > 
> > > > > > > diff --git a/xen/arch/x86/mm/mem_sharing.c 
> > > > > > > b/xen/arch/x86/mm/mem_sharing.c
> > > > > > > index 5f8f1fb4d871..99cf001fd70f 100644
> > > > > > > --- a/xen/arch/x86/mm/mem_sharing.c
> > > > > > > +++ b/xen/arch/x86/mm/mem_sharing.c
> > > > > > > @@ -1641,6 +1641,24 @@ static void copy_vcpu_nonreg_state(struct 
> > > > > > > vcpu *d_vcpu, struct vcpu *cd_vcpu)
> > > > > > >        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)
> > > > > > > +{
> > > > > > > +    unsigned int offset;
> > > > > > > +
> > > > > > > +    /* Check if no area to map, or already mapped. */
> > > > > > > +    if ( !d_area->pg || cd_area->pg )
> > > > > > > +        return 0;
> > > > > > > +
> > > > > > > +    offset = PAGE_OFFSET(d_area->map);
> > > > > > > +    return map_guest_area(cd_vcpu, gfn_to_gaddr(
> > > > > > > +                                       mfn_to_gfn(d, 
> > > > > > > page_to_mfn(d_area->pg))) +
> > > > > > > +                                   offset,
> > > > > > > +                          PAGE_SIZE - offset, cd_area, NULL);
> > > > > > > +}
> > > > > > > +
> > > > > > >    static int copy_vpmu(struct vcpu *d_vcpu, struct vcpu *cd_vcpu)
> > > > > > >    {
> > > > > > >        struct vpmu_struct *d_vpmu = vcpu_vpmu(d_vcpu);
> > > > > > > @@ -1709,6 +1727,16 @@ static int copy_vcpu_settings(struct 
> > > > > > > domain *cd, const struct domain *d)
> > > > > > >                    return ret;
> > > > > > >            }
> > > > > > > 
> > > > > > > +        /* 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;
> > > > > > > @@ -1950,7 +1978,10 @@ int mem_sharing_fork_reset(struct domain 
> > > > > > > *d, bool reset_state,
> > > > > > > 
> > > > > > >     state:
> > > > > > >        if ( reset_state )
> > > > > > > +    {
> > > > > > >            rc = copy_settings(d, pd);
> > > > > > > +        /* TBD: What to do here with -ERESTART? */
> > > > > > 
> > > > > > There is no situation where we get an -ERESTART here currently. Is
> > > > > > map_guest_area expected to run into situations where it fails with
> > > > > > that rc?
> > > > > 
> > > > > Yes, there's a spin_trylock() call that will result in
> > > > > map_guest_area() returning -ERESTART.
> > > > > 
> > > > > > If yes we might need a lock in place so we can block until it
> > > > > > can succeed.
> > > > > 
> > > > > I'm not sure whether returning -ERESTART can actually happen in
> > > > > map_guest_area() for the fork case: the child domain is still paused
> > > > > at this point, so there can't be concurrent guest hypercalls that
> > > > > would also cause the domain hypercall_deadlock_mutex to be acquired.
> > > 
> > > Perhaps turning it into an ASSERT(rc != -ERESTART) is the way to go at
> > > this point. If we run into any cases where it trips we can reason it
> > > out.
> > 
> > In order to avoid possibly returning -ERESTART (which should never be
> > seen by hypercall callers) we might want to convert it to -EBUSY and
> > let the caller pick the pieces.
> 
> I realize this is a matter of taste. I think EAGAIN is a better conversion
> for ERESTART because we effectively want to caller to try again.

That's fine with me, but could we leave adding such translation to a
further patch?

I would rather modify Jans code as less as possible.

Thanks, Roger.



 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.