From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-12.3 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH, MAILING_LIST_MULTI,NICE_REPLY_A,SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 1CD02C433E0 for ; Fri, 19 Mar 2021 10:23:52 +0000 (UTC) Received: from lists.xenproject.org (lists.xenproject.org [192.237.175.120]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id C687E64F38 for ; Fri, 19 Mar 2021 10:23:51 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org C687E64F38 Authentication-Results: mail.kernel.org; dmarc=fail (p=quarantine dis=none) header.from=suse.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=xen-devel-bounces@lists.xenproject.org Received: from list by lists.xenproject.org with outflank-mailman.99158.188355 (Exim 4.92) (envelope-from ) id 1lNCHb-0005mm-32; Fri, 19 Mar 2021 10:23:07 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 99158.188355; Fri, 19 Mar 2021 10:23:07 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1lNCHa-0005mf-Ue; Fri, 19 Mar 2021 10:23:06 +0000 Received: by outflank-mailman (input) for mailman id 99158; Fri, 19 Mar 2021 10:23:06 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1lNCHa-0005ma-3A for xen-devel@lists.xenproject.org; Fri, 19 Mar 2021 10:23:06 +0000 Received: from mx2.suse.de (unknown [195.135.220.15]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 9fda5cdf-89b1-4568-a9bf-434eaa21627e; Fri, 19 Mar 2021 10:23:05 +0000 (UTC) Received: from relay2.suse.de (unknown [195.135.221.27]) by mx2.suse.de (Postfix) with ESMTP id 29EA5ACC6; Fri, 19 Mar 2021 10:23:04 +0000 (UTC) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 9fda5cdf-89b1-4568-a9bf-434eaa21627e X-Virus-Scanned: by amavisd-new at test-mx.suse.de DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1; t=1616149384; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=wf7SiD2UhTJcHykNRnvUH7BeKEo3lRIyj9GVuRHdhs0=; b=XzAYZplBPi1nk98KJTdamJx0BAJxKo6DPBo/1XrwsLyYq91gEyVMs3g5n+qsHFL+g9r33I peZi7/ImobrLbfFaAXkin5rlx49q0P8Csg22Zzt8g0RoMLIBR5Yjo09OTCwOyZnrTdcDsL P1V38h9TuMyzFZl04Otk43Cix3lXjNU= Subject: Re: [PATCH for-4.15] x86/mem_sharing: copy parent VM's hostp2m's max_mapped_pfn during forking To: Tamas K Lengyel Cc: Tamas K Lengyel , Andrew Cooper , George Dunlap , =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= , Wei Liu , xen-devel@lists.xenproject.org References: From: Jan Beulich Message-ID: <193bfae5-a80a-d02a-377d-c9e11ad038a8@suse.com> Date: Fri, 19 Mar 2021 11:23:03 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.8.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit On 18.03.2021 22:36, Tamas K Lengyel wrote: > --- a/xen/arch/x86/mm/mem_sharing.c > +++ b/xen/arch/x86/mm/mem_sharing.c > @@ -1761,6 +1761,7 @@ static int copy_settings(struct domain *cd, struct domain *d) > return rc; > > copy_tsc(cd, d); > + p2m_get_hostp2m(cd)->max_mapped_pfn = p2m_get_hostp2m(d)->max_mapped_pfn; Makes sense to me, yes, but then an immediate question is: What about the somewhat similar {min,max}_remapped_gfn fields? Which of course implies the more general question of how alternate p2m-s (are supposed to) get treated in the first place. From my looking at it, fork() doesn't appear to also fork those, but also doesn't appear to refuse cloning when altp2m is in use. Jan