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

Re: [PATCH v4 5/9] x86/mem-sharing: copy GADDR based shared guest areas


  • To: Tamas K Lengyel <tamas@xxxxxxxxxxxxx>
  • From: Roger Pau Monné <roger.pau@xxxxxxxxxx>
  • Date: Fri, 29 Sep 2023 16:17:03 +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=ntp9RtGQDFqshZ2hLlhC/ZTLBjyevaTXr24A+tTXupo=; b=KVhgXXAuaXSz8rZvlmkDbTaGacoG8DF+n9cx9VYuhVf0Avsja9EAn6C4NsbZTU8Iw34Gk5bTWILJnNnWJMv4wxQqhCl5FI9X05csju09O52F52SVsTM/+/+KILsMZqSXIyMAmD2nLMoimdowBwjs7V8wyMlRJ1JOP0fPkzjcw2M/oILGc5Oz1u8aRnNC5RC26zj+8WIqALo0L5yIojngaykw0yS/cuPPSqCUCVcmP9wyrIDW6tjd53RnfLkoJ9htXIXpMyUnTEg1zK83Fu2Bqq1hhoi/JgWD7mFwxO5dzHXPOT7ZjRkDcXHVxrb45ahX/4vNag2JekL9PlxTBh9P4w==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=k4yQh2hRjwEg/iiyqhxEkjzomBIrJdhhz6CwR3qXzsWmpOR/Yx/i5XyNDT3uA1NqSzrTxLoUADvEW33C2l5XUr2Icu97jjl2UoFwaLQ1NcQN1/XCAGibijoOOfwId8LPi8nZOsx5pQo+YcdzsBzvRPxENtcYa30ZQ3zbHJH9+erE+vCI46D02XvEDKD3iMzCrknh5lq3HlsMQQawzuyhen9dVRBS7ghyNyQGYjh+lLPHpZfQqndRifckFI/reRaEQAMXw+qHTal4GTJzg/aV4T9DiTHQmcFa1j5N4QHXaymdBCVzRU9cNWxE6NaVZiSVY/StrDq/RJ6zhIJ9xxk5kA==
  • Authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=citrix.com;
  • Cc: Jan Beulich <jbeulich@xxxxxxxx>, "xen-devel@xxxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxxx>, Andrew Cooper <andrew.cooper3@xxxxxxxxxx>, George Dunlap <george.dunlap@xxxxxxxxxx>, Julien Grall <julien@xxxxxxx>, Stefano Stabellini <sstabellini@xxxxxxxxxx>, Wei Liu <wl@xxxxxxx>, Henry Wang <Henry.Wang@xxxxxxx>
  • Delivery-date: Fri, 29 Sep 2023 14:17:26 +0000
  • Ironport-data: A9a23:zF62RKpX28rrlax2gdOgMyUXDsteBmLuZBIvgKrLsJaIsI4StFCzt garIBmDMqvcYzf3ctt0PIrn9hgGvJbQndQ2GgVuqSpnHilDp5uZCYyVIHmrMnLJJKUvbq7FA +Y2MYCccZ9uHhcwgj/3b9ANeFEljfngqoLUUbOCYmYpA1Y8FE/NsDo788YhmIlknNOlNA2Ev NL2sqX3NUSsnjV5KQr40YrawP9UlKq04GhwUmAWP6gR5wePzShNVvrzGInqR5fGatgMdgKFb 76rIIGRpgvx4xorA9W5pbf3GmVirmn6ZFXmZtJ+AsBOszAazsAA+v9T2Mk0MC+7vw6hjdFpo OihgLTrIesf0g8gr8xGO/VQO3kW0aSrY9YrK1Dn2SCY5xWun3cBX5yCpaz5VGEV0r8fPI1Ay RAXADRdPxyKhPi1+pmYQcJI2fYYMODMEoxK7xmMzRmBZRonabbqZv2QoOR+hXI3jM0IGuvCb c0EbzYpdA7HfxBEJlYQDtQ5gfusgX78NTZfrTp5p4JuuzSVkFM3jeerbIW9lt+iHK25mm6Co W3L5SLhCwwyP92D0zuVtHmrg4cjmAuiAt5LReTkpq4CbFu7nkYOGTMkTWGAjeS1m22Vf/BhN EYqw397xUQ13AnxJjXnZDWkqXuNpTYAWN5dFeIr5QXLwa3Riy6bDGUZSj9KaPQ9qdQ7Azct0 zehj97vQDBirrCRYXac7auP6yO/PzAPKm0PbjNCShEKi/HhvYUygxTnXttlVqmvgbXdAirsy jqHqCw/gbQ7jsMR0ai/u1fdjFqEuZzhXgMzoALNUQqNzg5/fp/jWIWu5nDS9/MGJ4GcJmRtp 1ABksmaqfsIVJeEkXTXRP1XRO32ofGYLDfbnFhjWYE78Cig8GKieoYW5yxiIEBuMYAPfjqBj FLvhD69LaR7ZBOCBZKbqartYyj25cAMzejYa80=
  • Ironport-hdrordr: A9a23:q2/ZZKhveKpY6/RYVG7sXQ1sM3BQX/p23DAbv31ZSRFFG/FwyP rAoB1L73PJYWgqNU3IwerwQJVoMkmsjqKdgLNhS4tKMzOW3FdAQLsD0WKm+UyYJ8SczJ8V6U 4DSdkYNDSYNzET5qyVgTVQUexQpuVvm5rYw9s2uk0dKD2CHJsQjTuRZDzrcXFedU1jP94UBZ Cc7s1Iq36JfmkWVN2yAj0oTvXOvNrCkbPheFojCwQ84AeDoDu04PqieiLolSs2Yndq+/MP4G LFmwv26uGKtOy68AbV0yv+/olbg9zoz/pEHYiphtIOIjvhpw60bMBKWqGEvhoyvOazgWxa2O XkklMFBYBe+nnRdma6rV/GwA/7ygsj7Hfk1BuxnWbjidaRfkN2N+NxwaZiNjfJ4Uspu99xlI hR2XiCipZRBRTc2Azg+tnzUQ1wnEbcmwtvrQdTtQ0RbWItUs4RkWUtxjIULH7GJlO41GkTKp ghMCgb3ocVTbrVVQGdgoAl+q3XYp16JGb6fqFFgL3e7xFm2EljyU0W3coemWpF2q4cZvB/lq D5G5UtrapJSMAOa6J7GaMmeuuYTkLwYT+kChPUHbzAfJt3Y04lb6SHuYkd9aWkfocFw4A1n4 mEWFREtXQqc0arEsGW2oZXmyq9NVlVcA6duf223aIJyIHUVf7uK2mOWVoum8yvr7EWBdDaQe +6PNZTD+X4JWXjFI5V10mmMqMiXkU2QYkQoJI2SliOqsXEJsnjsfHaau/aIP7oHSw/Um3yD3 MfVHz4JdlG7EqsRnjk6SKhL0/Fawj659Z9AaLa9+8cxMwEMZBNqBEcjRCj6sSCOVR5w9wLlY tFUcLae4+A1BeLFDzznhlU0zJmfzlo3Ik=
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>

On Fri, Sep 29, 2023 at 08:31:58AM -0400, Tamas K Lengyel wrote:
> On Thu, Sep 28, 2023 at 10:08 AM Roger Pau Monné <roger.pau@xxxxxxxxxx> wrote:
> >
> > On Thu, Sep 28, 2023 at 08:57:04AM -0400, Tamas K Lengyel wrote:
> > > On Thu, Sep 28, 2023 at 7:08 AM Roger Pau Monné <roger.pau@xxxxxxxxxx> 
> > > wrote:
> > > >
> > > > On Thu, Sep 28, 2023 at 12:11:02PM +0200, Jan Beulich wrote:
> > > > > On 28.09.2023 11:51, Roger Pau Monné wrote:
> > > > > > On Thu, Sep 28, 2023 at 09:16:20AM +0200, Jan Beulich wrote:
> > > > > >> --- 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?
> > > > >
> > > > > Funny you should use this wording: P2M_ALLOC will deal with populating
> > > > > PoD slots, yes, but aiui forks don't fill their p2m with all PoD 
> > > > > slots,
> > > > > but rather leave them empty. Yet again I need to leave it to Tamas to
> > > > > confirm or prove me wrong.
> > > >
> > > > If the child p2m populating is only triggered by guest accesses then a
> > > > lot of hypercalls are likely to not work correctly on childs.
> > >
> > > That's not what's happening. As I said before, ALL access paths, be
> > > that from the guest, dom0 or Xen trigger page population. If there is
> > > a hole and P2M_ALLOC is set we do the following in
> > > p2m_get_gfn_type_access:
> > >
> > >     /* Check if we need to fork the page */
> > >     if ( (q & P2M_ALLOC) && p2m_is_hole(*t) &&
> > >          !mem_sharing_fork_page(p2m->domain, gfn, q & P2M_UNSHARE) )
> > >         mfn = p2m->get_entry(p2m, gfn, t, a, q, page_order, NULL);
> > >
> > > Depending on the type of access we either populate the hole with a
> > > shared memory entry or a copy.
> >
> > Then the code here is redundant, as the call to get_page_from_gfn(...,
> > P2M_UNSHARE) in map_vcpu_info() will already take care of populating
> > the child p2m and copy the parents page contents?
> 
> Reading the code now, yes, calling map_vcpu_info() would take care of
> populating the page for us as well so we can remove that code from
> mem_sharing.

Thanks for confirming.  Will try to prepare a patch next week to get
rid of the explicit child p2m populate for the vcpu_info page, and
hopefully simply the code here also as a result.

Roger.



 


Rackspace

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