Received: by 2002:a05:6a10:206:0:0:0:0 with SMTP id 6csp1230468pxj; Fri, 18 Jun 2021 02:31:09 -0700 (PDT) X-Google-Smtp-Source: ABdhPJyeDzCNTDM7JIyT80AG9i6r/aPUAw6EMV/HS+9ZbdkVZGeMI6hfoxFxHIJuosubpsUGAmkr X-Received: by 2002:a17:907:98eb:: with SMTP id ke11mr8385061ejc.85.1624008669022; Fri, 18 Jun 2021 02:31:09 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1624008668; cv=none; d=google.com; s=arc-20160816; b=QDv0nnM/cQsQyswUbr6i6uAY51JOfNBWur8CSlH3GM/4YsWCJMwU6q1opziO21OIdV EWAfYnXVj9ZhPO1/J5BnjV+BS6nN8T+H/Ecv6GH2a5JaDxgiv630urcCkYami/yeDqB1 xWG60nGeMEwQy18caxCg88J0+BrxHHQrfI9fvAOK8BAD3TFIHLyG72bkJn20/jj/YvQd z6iXuHTQFy9yqqWhdacG8czcp3Qluk3eGlmrG/qMsvvBsoafEbDL23dY+aQTtKltfmPd WNss/bdCVYk1ui8Yyp8dkQM2fAynWvm7+nch19FWxGjVuWe9IXJEk/X9RVur3llNELBz O7Zg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:dkim-signature; bh=jdFKobz0v5eVip0thXQlonp2mF35EnH4oN1hYfZc5Y8=; b=ZJIUn13HGi7yPYSKswMO/8XvziLkWyeuEjx51XLXVl1qto1+5l2UXuiY1EJsLV46Ik 5Qozn+2JWx47Dgu2JumRQ0AniktVOU+9kVJugUd5E5JcBXq7a9kHmnA+8BfxTmm3X3xE VW0VPFHe04R2a2qURzUH4cyz+25kaVJFrI0wRMhA0lud29wJntzBWR/1OtFDxb6czQRM PVEFWgXUEGEKvNvQng1Y5fIKvRNx6GHWMvB2tHXLQfWPVjx6BkhXuGhr7HYO9fPxZ/z4 Rj0W0ZiLk/B88gq0a1YRPOmxm5DYWe5j1Q+ke7d2wowP4WUgZwfd4LPTjXJwjFIVL4Pb 2Dzg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b=eaI1qif8; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id 26si1855771ejk.419.2021.06.18.02.30.44; Fri, 18 Jun 2021 02:31:08 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b=eaI1qif8; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231305AbhFRIwx (ORCPT + 99 others); Fri, 18 Jun 2021 04:52:53 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:53432 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229591AbhFRIww (ORCPT ); Fri, 18 Jun 2021 04:52:52 -0400 Received: from mail-oi1-x22a.google.com (mail-oi1-x22a.google.com [IPv6:2607:f8b0:4864:20::22a]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id E37BCC061574 for ; Fri, 18 Jun 2021 01:50:43 -0700 (PDT) Received: by mail-oi1-x22a.google.com with SMTP id t40so9774789oiw.8 for ; Fri, 18 Jun 2021 01:50:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=jdFKobz0v5eVip0thXQlonp2mF35EnH4oN1hYfZc5Y8=; b=eaI1qif8hWH4BDUPA4zAfU/JyLPIPsuOqFjMGM8Bena5fakXJe42h1NsUQcLTvKdJ1 LOcf3Qw8GQpYgpe1f/t5BZwAua9NJK/G8Q5YA0x3gEUix6SK0puD0UuAtx+522RhyFpH v4eUaoWuflGssbIsWGhZ4Q0auBg7DdWZVHDrnnwfk2+9LefFaGFSuIuQ9zld9KS8IFv6 Sd0rdtaCXNVsby6BzdgBjLciQorxLwS2MxQSfyQVweBhblWYkBi4L+gKasclg9l19zHq 1GMpCGCj40H2EsIOBz8dw37C0Qe0+/jP52+2bQikzN3ft8mTNr0GKkink3eqiPd9DNE/ sy/g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=jdFKobz0v5eVip0thXQlonp2mF35EnH4oN1hYfZc5Y8=; b=ShxYPiDsliJvbmW5v8mmiBeskbDhBD5ZklK38TlVDi1OKKPyP2e1J6VEN3EyR25aZC 5rLR0BxDA2yhTidXkeIxwkifYLePPXG4uzVzXjKA6bj7uiqTGitG2p+1Q2X8DCFUU+pi f6VXDM841vnkK0napgR7ZIe1i0VAHp4tzEvBpiS1GdY8w2NSNtfE+J6BjfLv6tOARMJS oV+UrmbkWoQZQFNu8heRDr5UZ87EOlaAyqsDdF9hku/AC8j3703zoQB7KDSbkdNNoFCZ enHh8DfXJ8iw8FZVtonHIwJiW1IKF8v5shJkSjvTtqjtb7Wz6/HzAONtpMyze34mpobv x9CQ== X-Gm-Message-State: AOAM531zUq7YdtICtSZS2Csl8Q37SMV03sD/FV1X7X0zp8L4VJC9xIkG aHUsEmBSktwW13HPQAg65IOFBEbZ8TRYDuA1p64GMg== X-Received: by 2002:aca:de07:: with SMTP id v7mr13635036oig.8.1624006243106; Fri, 18 Jun 2021 01:50:43 -0700 (PDT) MIME-Version: 1.0 References: <20210616095200.38008-1-wangyanan55@huawei.com> <20210616095200.38008-2-wangyanan55@huawei.com> In-Reply-To: <20210616095200.38008-2-wangyanan55@huawei.com> From: Fuad Tabba Date: Fri, 18 Jun 2021 09:50:06 +0100 Message-ID: Subject: Re: [PATCH v6 1/4] KVM: arm64: Introduce cache maintenance callbacks for guest stage-2 To: Yanan Wang Cc: Marc Zyngier , Will Deacon , 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 Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Yanan, On Wed, Jun 16, 2021 at 10:52 AM Yanan Wang wrote: > > To prepare for performing guest CMOs in the fault handlers in pgtable.c, > introduce two cache maintenance callbacks in struct kvm_pgtable_mm_ops. > > The new callbacks are specific for guest stage-2, so they will only be > initialized in 'struct kvm_pgtable_mm_ops kvm_s2_mm_ops'. > > Signed-off-by: Yanan Wang > --- > arch/arm64/include/asm/kvm_pgtable.h | 7 +++++++ > 1 file changed, 7 insertions(+) > > diff --git a/arch/arm64/include/asm/kvm_pgtable.h b/arch/arm64/include/asm/kvm_pgtable.h > index c3674c47d48c..302eca32e0af 100644 > --- a/arch/arm64/include/asm/kvm_pgtable.h > +++ b/arch/arm64/include/asm/kvm_pgtable.h > @@ -44,6 +44,11 @@ typedef u64 kvm_pte_t; > * in the current context. > * @virt_to_phys: Convert a virtual address mapped in the current context > * into a physical address. > + * @flush_dcache: Clean data cache for a guest page address range before > + * creating the corresponding stage-2 mapping. > + * @flush_icache: Invalidate instruction cache for a guest page address > + * range before creating or updating the corresponding > + * stage-2 mapping. > */ > struct kvm_pgtable_mm_ops { > void* (*zalloc_page)(void *arg); > @@ -54,6 +59,8 @@ struct kvm_pgtable_mm_ops { > int (*page_count)(void *addr); > void* (*phys_to_virt)(phys_addr_t phys); > phys_addr_t (*virt_to_phys)(void *addr); > + void (*flush_dcache)(void *addr, size_t size); > + void (*flush_icache)(void *addr, size_t size); > }; > Just to add to Marc's comment on naming, flush_dcache is in this case a clean and invalidate: I see that in patch 4 it eventually does a civac. So, yes, although it is a mouthful, I think it should be dcache_clean_inval and not just dcache_clean. An alternative, if it's acceptable by Marc and the others, is to name the parameters dcmo/icmo or something like that, where the nature of the maintenance operation is not necessarily tied to the name. For reference, this is the patch Marc mentioned, where we're trying to fix the naming to make it consistent with Arm terminology (Arm doesn't define what a flush is): https://lore.kernel.org/linux-arm-kernel/20210524083001.2586635-19-tabba@google.com/ Otherwise: Reviewed-by: Fuad Tabba Cheers, /fuad > /** > -- > 2.23.0 > > _______________________________________________ > kvmarm mailing list > kvmarm@lists.cs.columbia.edu > https://lists.cs.columbia.edu/mailman/listinfo/kvmarm