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

Re: [PATCH v2 1/3] x86/mem_sharing: option to enforce fork starting with empty p2m


  • To: Tamas K Lengyel <tamas.lengyel@xxxxxxxxx>
  • From: Jan Beulich <jbeulich@xxxxxxxx>
  • Date: Tue, 29 Mar 2022 17:42:35 +0200
  • Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=suse.com; dmarc=pass action=none header.from=suse.com; dkim=pass header.d=suse.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=yzW7+upfC/9vj6lPRwgSDHEMt44ugTfZCunqQLg8lQI=; b=A4o9P+nfUbDv5Lp2YUVWZak2OLuTEQzoeEJ+z1nv3hFfbAYmaA+TBvdvtVTLbIXlxvaqv1m56oSE41X0pC98E1KhGGbvGksEGKJySwq2ER4I80OeeiFGXc89PlP7CEy0fDDVcMwP5cbtfMSgC5vO+/1uhXpN9/XXfFxif7oWedvzcSkI21gMVOBUbYznbfde0YHybeII+sA99FL77McclKLTaL637fb6x6bWet0AA1YpH0+5wEqBU9C+sMGQGNSsIylAdKPS7NuJA1Rv5sK2BNviZAf9faGsPoxkU7haLoBMSpFPhqaoCO3TUGAotq11spM17lix5KUVRIRZ4Tp7xA==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=DZIou94oPy/UbaThzWNdEafRDdgleG0S9ttAQFXrMcFYKsi16czqeC6gslnOjWIdi5DvhkPogE/sDm14Oe9XVSdc+4RL4NuFDTuG13eCmeLMKEjtcOR1yABWNWi350bCaTU5WmkjqFQp0Ae5TF+YMZ4/W31aeMcnzjqRhRPSeACXH9jewW5aOf61T8cbTOQ81FZd533L6beV9jxOOHYQNW0fGSjulNXnIMZ2HZdh/mS95ul9ZabZ6VIEVtQ9GEbfqcF1mm7EJZSdDcj3/z0gGVYRqi8/vaU4hhmdAJUDnY7R3W4GV16q+YDajxhMdM4d5xpcncnRIfYoHUejK2/NtQ==
  • Authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=suse.com;
  • Cc: Wei Liu <wl@xxxxxxx>, Anthony PERARD <anthony.perard@xxxxxxxxxx>, Juergen Gross <jgross@xxxxxxxx>, Andrew Cooper <andrew.cooper3@xxxxxxxxxx>, George Dunlap <george.dunlap@xxxxxxxxxx>, Julien Grall <julien@xxxxxxx>, Stefano Stabellini <sstabellini@xxxxxxxxxx>, Jun Nakajima <jun.nakajima@xxxxxxxxx>, Kevin Tian <kevin.tian@xxxxxxxxx>, Roger Pau Monné <roger.pau@xxxxxxxxxx>, Tamas K Lengyel <tamas@xxxxxxxxxxxxx>, xen-devel@xxxxxxxxxxxxxxxxxxxx
  • Delivery-date: Tue, 29 Mar 2022 15:42:56 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>

On 29.03.2022 16:03, Tamas K Lengyel wrote:
> Add option to the fork memop to enforce a start with an empty p2m.
> Pre-populating special pages to the fork tend to be necessary only when 
> setting
> up forks to be fully functional with a toolstack or if the fork makes use of
> them in some way. For short-lived forks these pages are optional and starting
> with an empty p2m has advantages both in terms of reset performance as well as
> easier reasoning about the state of the fork after creation.

I'm afraid I don't consider this enough of an explanation: Why would these
page be optional? Where does the apriori knowledge come from that the guest
wouldn't manage to access the vCPU info pages or the APIC access one?

> --- a/xen/arch/x86/include/asm/hvm/domain.h
> +++ b/xen/arch/x86/include/asm/hvm/domain.h
> @@ -31,7 +31,9 @@
>  #ifdef CONFIG_MEM_SHARING
>  struct mem_sharing_domain
>  {
> -    bool enabled, block_interrupts;
> +    bool enabled;
> +    bool block_interrupts;
> +    bool empty_p2m;

While the name of the field is perhaps fine as is, it would be helpful to
have a comment here clarifying that this is only about the guest's initial
and reset state; this specifically does not indicate the p2m has to remain
empty (aiui).

> @@ -1856,7 +1860,13 @@ static int fork(struct domain *cd, struct domain *d)
>      if ( (rc = bring_up_vcpus(cd, d)) )
>          goto done;
>  
> -    rc = copy_settings(cd, d);
> +    if ( !(rc = copy_settings(cd, d, empty_p2m)) )
> +    {
> +        cd->arch.hvm.mem_sharing.block_interrupts = block_interrupts;
> +
> +        if ( (cd->arch.hvm.mem_sharing.empty_p2m = empty_p2m) )

Is there a reason you don't do the assignment earlier, thus avoiding the
need to pass around the extra function argument?

> --- a/xen/include/public/memory.h
> +++ b/xen/include/public/memory.h
> @@ -543,10 +543,10 @@ struct xen_mem_sharing_op {
>          } debug;
>          struct mem_sharing_op_fork {      /* OP_FORK */
>              domid_t parent_domain;        /* IN: parent's domain id */
> -/* Only makes sense for short-lived forks */
> +/* These flags only makes sense for short-lived forks */

Nit: s/makes/make/.

Jan




 


Rackspace

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