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.7 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,INCLUDES_PATCH,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 autolearn=unavailable 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 DB0E0C49361 for ; Thu, 17 Jun 2021 13:21:24 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id C470D613BA for ; Thu, 17 Jun 2021 13:21:24 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232429AbhFQNXb (ORCPT ); Thu, 17 Jun 2021 09:23:31 -0400 Received: from mail.kernel.org ([198.145.29.99]:58282 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231702AbhFQNX3 (ORCPT ); Thu, 17 Jun 2021 09:23:29 -0400 Received: by mail.kernel.org (Postfix) with ESMTPSA id BD02A6112D; Thu, 17 Jun 2021 13:21:19 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1623936082; bh=9m33aIOJbia+ShcJ940DomACgwPzr98gLkW2wr4hC0U=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=Vb3e9ZS14SiSso4EXORRrKwxfAZT20KMhCseWc54VYAc5MtG70waEtim/es9NVznb KZxnCTX+u/dwRN/5pESaYM3FZpZSC05Lqzsa5HbAJrOk43pEdk/krdZ10NrbEYSBzu HfhjoHpdabOfk6XKx0eib42VKJhHjwqmBoyD6YKubuKZB9QC7T1Ifr9yD+K3eflqBc uKupbuBOkbtc6w8EBmowP9qnR7esHF7xQpck+/SAfRDdi3Ub4ts1YhYRx3ohwTp1Rp vjynNariT2gyLgNMJbZfqpwB/XC45+n+U4u5f4GgnvMLcdI2596NypKVEF6jSxtVED B4DjgJJgNh+Lw== Date: Thu, 17 Jun 2021 14:21:16 +0100 From: Will Deacon To: Marc Zyngier Cc: Yanan Wang , Quentin Perret , Alexandru Elisei , kvmarm@lists.cs.columbia.edu, linux-arm-kernel@lists.infradead.org, kvm@vger.kernel.org, linux-kernel@vger.kernel.org, Catalin Marinas , James Morse , Julien Thierry , Suzuki K Poulose , Gavin Shan , wanghaibin.wang@huawei.com, zhukeqian1@huawei.com, yuzenghui@huawei.com Subject: Re: [PATCH v7 4/4] KVM: arm64: Move guest CMOs to the fault handlers Message-ID: <20210617132115.GA24656@willie-the-truck> References: <20210617105824.31752-1-wangyanan55@huawei.com> <20210617105824.31752-5-wangyanan55@huawei.com> <20210617124557.GB24457@willie-the-truck> <87k0msd4ue.wl-maz@kernel.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <87k0msd4ue.wl-maz@kernel.org> User-Agent: Mutt/1.10.1 (2018-07-13) Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Jun 17, 2021 at 01:59:37PM +0100, Marc Zyngier wrote: > On Thu, 17 Jun 2021 13:45:57 +0100, > Will Deacon wrote: > > On Thu, Jun 17, 2021 at 06:58:24PM +0800, Yanan Wang wrote: > > > @@ -606,6 +618,14 @@ static int stage2_map_walker_try_leaf(u64 addr, u64 end, u32 level, > > > stage2_put_pte(ptep, data->mmu, addr, level, mm_ops); > > > } > > > > > > + /* Perform CMOs before installation of the guest stage-2 PTE */ > > > + if (mm_ops->clean_invalidate_dcache && stage2_pte_cacheable(pgt, new)) > > > + mm_ops->clean_invalidate_dcache(kvm_pte_follow(new, mm_ops), > > > + granule); > > > + > > > + if (mm_ops->invalidate_icache && stage2_pte_executable(new)) > > > + mm_ops->invalidate_icache(kvm_pte_follow(new, mm_ops), granule); > > > > One thing I'm missing here is why we need the indirection via mm_ops. Are > > there cases where we would want to pass a different function pointer for > > invalidating the icache? If not, why not just call the function directly? > > > > Same for the D side. > > If we didn't do that, we'd end-up having to track whether the guest > context requires CMOs with additional flags, which is pretty ugly (see > v5 of this series for reference [1]). Fair enough, although the function pointers here _are_ being used as flags, as they only ever have one of two possible values (NULL or the CMO function), so it's a shame to bring in the indirect branch as well. > It also means that we would have to drag the CM functions into the EL2 > object, something that we don't need with this approach. I think it won't be long before we end up with CMO functions at EL2 and you'd hope we'd be able to use the same code as EL1 for something like that. But I also wouldn't want to put money on it... Anyway, no strong opinion on this, it just jumped out when I skimmed the patches. Will 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=-10.3 required=3.0 tests=BAYES_00,DKIM_INVALID, DKIM_SIGNED,INCLUDES_PATCH,MAILING_LIST_MULTI,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 A9BCDC2B9F4 for ; Thu, 17 Jun 2021 13:21:27 +0000 (UTC) Received: from mm01.cs.columbia.edu (mm01.cs.columbia.edu [128.59.11.253]) by mail.kernel.org (Postfix) with ESMTP id 365A4613BA for ; Thu, 17 Jun 2021 13:21:27 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 365A4613BA Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=kernel.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=kvmarm-bounces@lists.cs.columbia.edu Received: from localhost (localhost [127.0.0.1]) by mm01.cs.columbia.edu (Postfix) with ESMTP id BBE434056A; Thu, 17 Jun 2021 09:21:26 -0400 (EDT) X-Virus-Scanned: at lists.cs.columbia.edu Authentication-Results: mm01.cs.columbia.edu (amavisd-new); dkim=softfail (fail, message has been altered) header.i=@kernel.org Received: from mm01.cs.columbia.edu ([127.0.0.1]) by localhost (mm01.cs.columbia.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j8sRx4JV2UCT; Thu, 17 Jun 2021 09:21:25 -0400 (EDT) Received: from mm01.cs.columbia.edu (localhost [127.0.0.1]) by mm01.cs.columbia.edu (Postfix) with ESMTP id 052F54A4A0; Thu, 17 Jun 2021 09:21:25 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mm01.cs.columbia.edu (Postfix) with ESMTP id 5AF98407B0 for ; Thu, 17 Jun 2021 09:21:24 -0400 (EDT) X-Virus-Scanned: at lists.cs.columbia.edu Received: from mm01.cs.columbia.edu ([127.0.0.1]) by localhost (mm01.cs.columbia.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LhTYmKlRBk2y for ; Thu, 17 Jun 2021 09:21:23 -0400 (EDT) Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by mm01.cs.columbia.edu (Postfix) with ESMTPS id 47CFC4056A for ; Thu, 17 Jun 2021 09:21:23 -0400 (EDT) Received: by mail.kernel.org (Postfix) with ESMTPSA id BD02A6112D; Thu, 17 Jun 2021 13:21:19 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1623936082; bh=9m33aIOJbia+ShcJ940DomACgwPzr98gLkW2wr4hC0U=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=Vb3e9ZS14SiSso4EXORRrKwxfAZT20KMhCseWc54VYAc5MtG70waEtim/es9NVznb KZxnCTX+u/dwRN/5pESaYM3FZpZSC05Lqzsa5HbAJrOk43pEdk/krdZ10NrbEYSBzu HfhjoHpdabOfk6XKx0eib42VKJhHjwqmBoyD6YKubuKZB9QC7T1Ifr9yD+K3eflqBc uKupbuBOkbtc6w8EBmowP9qnR7esHF7xQpck+/SAfRDdi3Ub4ts1YhYRx3ohwTp1Rp vjynNariT2gyLgNMJbZfqpwB/XC45+n+U4u5f4GgnvMLcdI2596NypKVEF6jSxtVED B4DjgJJgNh+Lw== Date: Thu, 17 Jun 2021 14:21:16 +0100 From: Will Deacon To: Marc Zyngier Subject: Re: [PATCH v7 4/4] KVM: arm64: Move guest CMOs to the fault handlers Message-ID: <20210617132115.GA24656@willie-the-truck> References: <20210617105824.31752-1-wangyanan55@huawei.com> <20210617105824.31752-5-wangyanan55@huawei.com> <20210617124557.GB24457@willie-the-truck> <87k0msd4ue.wl-maz@kernel.org> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <87k0msd4ue.wl-maz@kernel.org> User-Agent: Mutt/1.10.1 (2018-07-13) Cc: kvm@vger.kernel.org, Catalin Marinas , linux-kernel@vger.kernel.org, kvmarm@lists.cs.columbia.edu, linux-arm-kernel@lists.infradead.org X-BeenThere: kvmarm@lists.cs.columbia.edu X-Mailman-Version: 2.1.14 Precedence: list List-Id: Where KVM/ARM decisions are made List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: kvmarm-bounces@lists.cs.columbia.edu Sender: kvmarm-bounces@lists.cs.columbia.edu On Thu, Jun 17, 2021 at 01:59:37PM +0100, Marc Zyngier wrote: > On Thu, 17 Jun 2021 13:45:57 +0100, > Will Deacon wrote: > > On Thu, Jun 17, 2021 at 06:58:24PM +0800, Yanan Wang wrote: > > > @@ -606,6 +618,14 @@ static int stage2_map_walker_try_leaf(u64 addr, u64 end, u32 level, > > > stage2_put_pte(ptep, data->mmu, addr, level, mm_ops); > > > } > > > > > > + /* Perform CMOs before installation of the guest stage-2 PTE */ > > > + if (mm_ops->clean_invalidate_dcache && stage2_pte_cacheable(pgt, new)) > > > + mm_ops->clean_invalidate_dcache(kvm_pte_follow(new, mm_ops), > > > + granule); > > > + > > > + if (mm_ops->invalidate_icache && stage2_pte_executable(new)) > > > + mm_ops->invalidate_icache(kvm_pte_follow(new, mm_ops), granule); > > > > One thing I'm missing here is why we need the indirection via mm_ops. Are > > there cases where we would want to pass a different function pointer for > > invalidating the icache? If not, why not just call the function directly? > > > > Same for the D side. > > If we didn't do that, we'd end-up having to track whether the guest > context requires CMOs with additional flags, which is pretty ugly (see > v5 of this series for reference [1]). Fair enough, although the function pointers here _are_ being used as flags, as they only ever have one of two possible values (NULL or the CMO function), so it's a shame to bring in the indirect branch as well. > It also means that we would have to drag the CM functions into the EL2 > object, something that we don't need with this approach. I think it won't be long before we end up with CMO functions at EL2 and you'd hope we'd be able to use the same code as EL1 for something like that. But I also wouldn't want to put money on it... Anyway, no strong opinion on this, it just jumped out when I skimmed the patches. Will _______________________________________________ kvmarm mailing list kvmarm@lists.cs.columbia.edu https://lists.cs.columbia.edu/mailman/listinfo/kvmarm 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=-10.7 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,INCLUDES_PATCH,MAILING_LIST_MULTI,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 86ADBC49361 for ; Thu, 17 Jun 2021 13:23:00 +0000 (UTC) Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (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 4FA776112D for ; Thu, 17 Jun 2021 13:23:00 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 4FA776112D Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=kernel.org Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References: Message-ID:Subject:Cc:To:From:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=Czus0h7ErX0BjXKdSmPHHuigC0vPisCOGrkKvVoYV/8=; b=h/29xmPgFisFrm URgrDLlD4unmZocc99J+sPNBbxb9i2KWrRuDcBpIGkUWwll9+XoCdBaKsGW7a0Wq4IVeqFDl4/wYE lokM7O1jBWjN2h/5q97GpQpQdA3OakTqytAloYbCDxF9CmSClR/+u9b+gfo1hFd4G9vyj8zEELRkz uaPf4WWXAhyp/kXVZMspmHaprJ7wFi4A0KGA+LVrB2ngxx/U8Ms7YwfIwG3rACt8bvognccG5fRY8 hlsFYZ+qEmtTYxxVQ72LpuAQJsX1MneoAvAVW6D9ynDPEMQAWjfOMyIKD6gstYUCd0STbvIzbsJ/H KXtuMGOkIMLuSdbqs3MA==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1ltrxc-00ARpq-Jf; Thu, 17 Jun 2021 13:21:32 +0000 Received: from mail.kernel.org ([198.145.29.99]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1ltrxS-00ARnL-RS for linux-arm-kernel@lists.infradead.org; Thu, 17 Jun 2021 13:21:24 +0000 Received: by mail.kernel.org (Postfix) with ESMTPSA id BD02A6112D; Thu, 17 Jun 2021 13:21:19 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1623936082; bh=9m33aIOJbia+ShcJ940DomACgwPzr98gLkW2wr4hC0U=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=Vb3e9ZS14SiSso4EXORRrKwxfAZT20KMhCseWc54VYAc5MtG70waEtim/es9NVznb KZxnCTX+u/dwRN/5pESaYM3FZpZSC05Lqzsa5HbAJrOk43pEdk/krdZ10NrbEYSBzu HfhjoHpdabOfk6XKx0eib42VKJhHjwqmBoyD6YKubuKZB9QC7T1Ifr9yD+K3eflqBc uKupbuBOkbtc6w8EBmowP9qnR7esHF7xQpck+/SAfRDdi3Ub4ts1YhYRx3ohwTp1Rp vjynNariT2gyLgNMJbZfqpwB/XC45+n+U4u5f4GgnvMLcdI2596NypKVEF6jSxtVED B4DjgJJgNh+Lw== Date: Thu, 17 Jun 2021 14:21:16 +0100 From: Will Deacon To: Marc Zyngier Cc: Yanan Wang , Quentin Perret , Alexandru Elisei , kvmarm@lists.cs.columbia.edu, linux-arm-kernel@lists.infradead.org, kvm@vger.kernel.org, linux-kernel@vger.kernel.org, Catalin Marinas , James Morse , Julien Thierry , Suzuki K Poulose , Gavin Shan , wanghaibin.wang@huawei.com, zhukeqian1@huawei.com, yuzenghui@huawei.com Subject: Re: [PATCH v7 4/4] KVM: arm64: Move guest CMOs to the fault handlers Message-ID: <20210617132115.GA24656@willie-the-truck> References: <20210617105824.31752-1-wangyanan55@huawei.com> <20210617105824.31752-5-wangyanan55@huawei.com> <20210617124557.GB24457@willie-the-truck> <87k0msd4ue.wl-maz@kernel.org> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <87k0msd4ue.wl-maz@kernel.org> User-Agent: Mutt/1.10.1 (2018-07-13) X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20210617_062122_961143_B0F29C56 X-CRM114-Status: GOOD ( 17.69 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Thu, Jun 17, 2021 at 01:59:37PM +0100, Marc Zyngier wrote: > On Thu, 17 Jun 2021 13:45:57 +0100, > Will Deacon wrote: > > On Thu, Jun 17, 2021 at 06:58:24PM +0800, Yanan Wang wrote: > > > @@ -606,6 +618,14 @@ static int stage2_map_walker_try_leaf(u64 addr, u64 end, u32 level, > > > stage2_put_pte(ptep, data->mmu, addr, level, mm_ops); > > > } > > > > > > + /* Perform CMOs before installation of the guest stage-2 PTE */ > > > + if (mm_ops->clean_invalidate_dcache && stage2_pte_cacheable(pgt, new)) > > > + mm_ops->clean_invalidate_dcache(kvm_pte_follow(new, mm_ops), > > > + granule); > > > + > > > + if (mm_ops->invalidate_icache && stage2_pte_executable(new)) > > > + mm_ops->invalidate_icache(kvm_pte_follow(new, mm_ops), granule); > > > > One thing I'm missing here is why we need the indirection via mm_ops. Are > > there cases where we would want to pass a different function pointer for > > invalidating the icache? If not, why not just call the function directly? > > > > Same for the D side. > > If we didn't do that, we'd end-up having to track whether the guest > context requires CMOs with additional flags, which is pretty ugly (see > v5 of this series for reference [1]). Fair enough, although the function pointers here _are_ being used as flags, as they only ever have one of two possible values (NULL or the CMO function), so it's a shame to bring in the indirect branch as well. > It also means that we would have to drag the CM functions into the EL2 > object, something that we don't need with this approach. I think it won't be long before we end up with CMO functions at EL2 and you'd hope we'd be able to use the same code as EL1 for something like that. But I also wouldn't want to put money on it... Anyway, no strong opinion on this, it just jumped out when I skimmed the patches. Will _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel