Received: by 2002:a05:6358:a55:b0:ec:fcf4:3ecf with SMTP id 21csp3526059rwb; Mon, 16 Jan 2023 09:06:47 -0800 (PST) X-Google-Smtp-Source: AMrXdXtLGayRb7SCL3jb6ZdfG5Lz9NbJJdR7XjLKEfxg5m1ei/LC9Dw7gSXv7TASLqiZrwBaqsOy X-Received: by 2002:a05:6402:3985:b0:467:9976:2e38 with SMTP id fk5-20020a056402398500b0046799762e38mr86415248edb.18.1673888807615; Mon, 16 Jan 2023 09:06:47 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1673888807; cv=none; d=google.com; s=arc-20160816; b=j0Sl5HdV5fXyU4/D+UFN6Dna9KFRa5WOneX2x0e+lSy00iDQGFlCtZQHdxenImqM7V LqQJAKSU6pW0EImwhX1n/WbM3C1EJvgyTBXRRcNewPwx3mpz2oQiBeKL4oNTI5Sdk6zq E6Og7yS8NFFPS+hH4GSUoi555iMwqu1p6wcvT9KQYEU7Cp0y7vHFSBHSYiAjlxisFEXG UZiHG+FprDZoQZfrmFW2kmlv7IzTJsqMkm5ZeEiKVX6yrkxnRpytOTv7vI+LDAWHJMly z+0nIneJZLhsrQZ00K8nWcAkuV5GVQsic8KBG74s7kxa9ECCW9+DxChV9cMjoG+ctXtm EVMw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:content-language :in-reply-to:mime-version:user-agent:date:message-id:from:references :cc:to:subject; bh=pjzN8YBCAh+7YkIiYE6WslfHanrogriHGnJnsJKx43c=; b=a6QTlK5PRHa3fHBnzohSrY4Fdu+Sfw0B0aEJ2CCMDvwMHQKmrGjaFo/i/4+cMHeMp4 CSxc09r4sLS7rO70Mk2D/iotzcW4GCjl3NzCvXepv0bEE0rZmzIJ16xrrAdJ7tlBpDvb QnZ0XaKSkDqzzhpkYuNgt4YsnFsjtAF5AnTqtcQTCr/32rDjIOB0rpk77G4wQIxVRy61 Ln8dfXZVh6GzRrQI6CC81WGumhNqVMgPQNjQ/+ECSQgQjcokOo6Bb38aoHbiRW/FYTPn Szml7tfcnz5l2L4Awd6SSAK/QaygVRouocyc6a33aQHavrhz/pVtg3SRpfte4jB8ydx9 nPTg== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=mit.edu Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id b7-20020a056402084700b00477e491fe37si8607149edz.509.2023.01.16.09.06.34; Mon, 16 Jan 2023 09:06:47 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=mit.edu Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233009AbjAPQUh (ORCPT + 50 others); Mon, 16 Jan 2023 11:20:37 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:38214 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232818AbjAPQUJ (ORCPT ); Mon, 16 Jan 2023 11:20:09 -0500 Received: from outgoing2021.csail.mit.edu (outgoing2021.csail.mit.edu [128.30.2.78]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id CA3332FCCC for ; Mon, 16 Jan 2023 08:10:47 -0800 (PST) Received: from c-24-17-218-140.hsd1.wa.comcast.net ([24.17.218.140] helo=srivatsab3MD6R.vmware.com) by outgoing2021.csail.mit.edu with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.95) (envelope-from ) id 1pHS49-00Ec49-Pd; Mon, 16 Jan 2023 11:10:33 -0500 Subject: Re: [PATCH] x86/paravirt: merge activate_mm and dup_mmap callbacks To: Juergen Gross , linux-kernel@vger.kernel.org, x86@kernel.org, virtualization@lists.linux-foundation.org Cc: Thomas Gleixner , Ingo Molnar , Borislav Petkov , Dave Hansen , "H. Peter Anvin" , Alexey Makhalov , VMware PV-Drivers Reviewers , Boris Ostrovsky , xen-devel@lists.xenproject.org References: <20230112152132.4399-1-jgross@suse.com> <3fcb5078-852e-0886-c084-7fb0cfa5b757@csail.mit.edu> <27d08d32-1a17-0959-203f-39e769f555d1@suse.com> From: "Srivatsa S. Bhat" Message-ID: <6a8e25eb-758d-8ad6-23c1-5fea7dab3b09@csail.mit.edu> Date: Mon, 16 Jan 2023 08:10:30 -0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.12.0 MIME-Version: 1.0 In-Reply-To: <27d08d32-1a17-0959-203f-39e769f555d1@suse.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00,NICE_REPLY_A, SPF_HELO_NONE,SPF_PASS autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 1/15/23 10:43 PM, Juergen Gross wrote: > On 16.01.23 05:27, Srivatsa S. Bhat wrote: >> >> Hi Juergen, >> >> On 1/12/23 7:21 AM, Juergen Gross wrote: >>> The two paravirt callbacks .mmu.activate_mm and .mmu.dup_mmap are >>> sharing the same implementations in all cases: for Xen PV guests they >>> are pinning the PGD of the new mm_struct, and for all other cases >>> they are a NOP. >>> >> >> I was expecting that the duplicated functions xen_activate_mm() and >> xen_dup_mmap() would be merged into a common one, and that both >> .mmu.activate_mm and .mmu.dup_mmap callbacks would be mapped to that >> common implementation for Xen PV. >> >>> So merge them to a common callback .mmu.enter_mmap (in contrast to the >>> corresponding already existing .mmu.exit_mmap). >>> >> >> Instead, this patch seems to be merging the callbacks themselves... >> >> I see that's not an issue right now since there is no other actual >> user for these callbacks. But are we sure that merging the callbacks >> just because the current user (Xen PV) has the same implementation for >> both is a good idea? The callbacks are invoked at distinct points from >> fork/exec, so wouldn't it be valuable to retain that distinction in >> semantics in the callbacks as well? >> >> However, if you believe that two separate callbacks are not really >> required here (because there is no significant difference in what they >> mean, rather than because their callback implementations happen to be >> the same right now), then could you please expand on this and call it >> out in the commit message, please? > > Would you be fine with: > >   In the end both callbacks are meant to register an address space with the >   underlying hypervisor, so there needs to be only a single callback for that >   purpose. > Sure, that looks good. Thank you! Regards, Srivatsa VMware Photon OS