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 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 89A10C433FE for ; Thu, 7 Oct 2021 15:38:20 +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 50C2A61245 for ; Thu, 7 Oct 2021 15:38:20 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 50C2A61245 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=redhat.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=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=CaoF3LQGjewdFiDMqURrYr9M224hjfzRHiJWi/rpFyM=; b=EgYf1MjcgnGxU5 nMM7G2OnrUjS6CuVhQADUqKiHpGyYKjCiYdGJA62iPJVQRelTkKAH43IfeOWjapHox2cDbjX1T3Di GnubXPpdTmkL5S3pYuB7+v1Ikf0vDnZ3msIRzufddDd0n6E5leYLw0vvC9Qnni+UDSA8IR0XozZ2P jEZix4eRpyTxNAIGc2PTP5KEnDbiMvcY7Nq6I9nclsvM+0RjgioVANEFs4PuAquxoumGH4g/c+9dj Kj7sJ40bPpbHVzYUm7VSk8+deLEboAOGqawE2WTaAitNweUdvoZK3LGoK6pVcjyf60Tffprk3xmbo ro1gcEc5p9QOwBZAiTdg==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1mYVRM-000AAm-0P; Thu, 07 Oct 2021 15:36:12 +0000 Received: from us-smtp-delivery-124.mimecast.com ([216.205.24.124]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1mYVRI-000A9q-P8 for linux-arm-kernel@lists.infradead.org; Thu, 07 Oct 2021 15:36:10 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1633620967; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=uAG2gSfGivkFqPdUcOcMoHWNK+3LPbOEp8js+1JX9D0=; b=CSR2qIOkpznwEp89vDXGcsniL/5XrYF5Xi2keeAWlvuMT3ik7Ri9ky8CI/oimsHdPSi2tl jDAkoK3d07Wl0VQnUc3B0qS1qTGr48TMtWXpdOr++YAAV8XXcXyMpuKPnokKOr2dq43Ab+ /Ot8Ttcd19hYEkdLcjXyGAYYvwoQLaM= Received: from mail-wr1-f70.google.com (mail-wr1-f70.google.com [209.85.221.70]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-547-h8FU7pXlP9qst1in-MTH2Q-1; Thu, 07 Oct 2021 11:36:06 -0400 X-MC-Unique: h8FU7pXlP9qst1in-MTH2Q-1 Received: by mail-wr1-f70.google.com with SMTP id e12-20020a056000178c00b001606927de88so5017394wrg.10 for ; Thu, 07 Oct 2021 08:36:05 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=uAG2gSfGivkFqPdUcOcMoHWNK+3LPbOEp8js+1JX9D0=; b=sJGv9iz93vE578aG+RB5YX21yu6uY25jHPl4Tw9ayjOW/LswLtevLcpT6zTvbS4TxB /ZisplSItP4xq9292LwQXvueKzOEbfrtqIltTbMimh6IO5P66Zq6xye0wB1go6Ot4sJm q221hBKZ2CGKvWZ4U21nnUhCmmQQX3WMdf3FPcuJ21d5n14awWNrsIcY7wjpAV75KBjB z/KB48R4+potQvB0d6CfQr0wPHqd0TbZ8uLkc7PCja9P3DQRXMekBEa9+5MlMsT0Abpw MrMKHkmbhnrmo+vC5QLga9EUV8xzXmLhYlJK30+vEZm5vpfbMd3OJFwcgVwJLLLQHd1F vCnA== X-Gm-Message-State: AOAM532WTCWmua4LyYfq0ANPKFkeedzurRn0979frrj69lPwjuzcEw7K J2z3VUTbAg62mN/Oleb+h1qadQn9vNiQE7MfdCKPhf0nRwr65TsQu9Gbc0Khnz0+zQqvqrStR0v /DQcZL1Gnzj96Nf117xKrQB1OnERVF+c5Fz0= X-Received: by 2002:a5d:6b03:: with SMTP id v3mr6309721wrw.226.1633620964993; Thu, 07 Oct 2021 08:36:04 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzOKhb13upVjPdpIgw2cu/kQXMovUZ4V+HV98DQtzXtkqpTYLB5D5upVw8rRtM4pTWx6MSkgA== X-Received: by 2002:a5d:6b03:: with SMTP id v3mr6309692wrw.226.1633620964837; Thu, 07 Oct 2021 08:36:04 -0700 (PDT) Received: from gator (nat-pool-brq-u.redhat.com. [213.175.37.12]) by smtp.gmail.com with ESMTPSA id z1sm20480911wrt.41.2021.10.07.08.36.03 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 07 Oct 2021 08:36:04 -0700 (PDT) Date: Thu, 7 Oct 2021 17:36:02 +0200 From: Andrew Jones To: Marc Zyngier Cc: linux-arm-kernel@lists.infradead.org, kvmarm@lists.cs.columbia.edu, kvm@vger.kernel.org, linux-kernel@vger.kernel.org, will@kernel.org, qperret@google.com, dbrazdil@google.com, Steven Price , Fuad Tabba , Srivatsa Vaddagiri , Shanker R Donthineni , James Morse , Suzuki K Poulose , Alexandru Elisei , kernel-team@android.com Subject: Re: [PATCH v2 13/16] arm64: Implement ioremap/iounmap hooks calling into KVM's MMIO guard Message-ID: <20211007153602.ty72qbglrwbphokj@gator> References: <20211004174849.2831548-1-maz@kernel.org> <20211004174849.2831548-14-maz@kernel.org> MIME-Version: 1.0 In-Reply-To: <20211004174849.2831548-14-maz@kernel.org> Authentication-Results: relay.mimecast.com; auth=pass smtp.auth=CUSA124A263 smtp.mailfrom=drjones@redhat.com X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Disposition: inline X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20211007_083608_928130_17E1F0B0 X-CRM114-Status: GOOD ( 25.71 ) 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 Mon, Oct 04, 2021 at 06:48:46PM +0100, Marc Zyngier wrote: > Implement the previously defined ioremap/iounmap hooks for arm64, > calling into KVM's MMIO guard if available. > > Signed-off-by: Marc Zyngier > --- > arch/arm64/mm/ioremap.c | 112 ++++++++++++++++++++++++++++++++++++++++ > 1 file changed, 112 insertions(+) > > diff --git a/arch/arm64/mm/ioremap.c b/arch/arm64/mm/ioremap.c > index b7c81dacabf0..5334cbdc9f64 100644 > --- a/arch/arm64/mm/ioremap.c > +++ b/arch/arm64/mm/ioremap.c > @@ -9,13 +9,125 @@ > * Copyright (C) 2012 ARM Ltd. > */ > > +#define pr_fmt(fmt) "ioremap: " fmt > + > #include > #include > #include > +#include > #include > +#include > > #include > #include > +#include > + > +struct ioremap_guard_ref { > + refcount_t count; > +}; > + > +static DEFINE_STATIC_KEY_FALSE(ioremap_guard_key); > +static DEFINE_XARRAY(ioremap_guard_array); > +static DEFINE_MUTEX(ioremap_guard_lock); > + > +void ioremap_phys_range_hook(phys_addr_t phys_addr, size_t size, pgprot_t prot) > +{ > + if (!static_branch_unlikely(&ioremap_guard_key)) > + return; > + > + if (pfn_valid(__phys_to_pfn(phys_addr))) > + return; > + > + mutex_lock(&ioremap_guard_lock); > + > + while (size) { > + u64 pfn = phys_addr >> PAGE_SHIFT; > + struct ioremap_guard_ref *ref; > + struct arm_smccc_res res; > + > + ref = xa_load(&ioremap_guard_array, pfn); > + if (ref) { > + refcount_inc(&ref->count); > + goto next; > + } > + > + /* > + * It is acceptable for the allocation to fail, specially > + * if trying to ioremap something very early on, like with > + * earlycon, which happens long before kmem_cache_init. > + * This page will be permanently accessible, similar to a > + * saturated refcount. > + */ > + ref = kzalloc(sizeof(*ref), GFP_KERNEL); > + if (ref) { > + refcount_set(&ref->count, 1); > + if (xa_err(xa_store(&ioremap_guard_array, pfn, ref, > + GFP_KERNEL))) { > + kfree(ref); > + ref = NULL; > + } > + } > + > + arm_smccc_1_1_hvc(ARM_SMCCC_VENDOR_HYP_KVM_MMIO_GUARD_MAP_FUNC_ID, > + phys_addr, prot, &res); OK, I see this follows the document and passes prot in x2, even though the hypercall implementation doesn't look at it [yet]. > + if (res.a0 != SMCCC_RET_SUCCESS) { > + pr_warn_ratelimited("Failed to register %llx\n", > + phys_addr); > + xa_erase(&ioremap_guard_array, pfn); > + kfree(ref); > + goto out; > + } > + > + next: > + size -= PAGE_SIZE; > + phys_addr += PAGE_SIZE; Looks like we're assuming the guard granule to be PAGE_SIZE here. Looking ahead at the next patch, I see it must be PAGE_SIZE, because if the info hypercall doesn't have a matching value, then mmio guarding doesn't happen at all. Maybe it should be documented that for this feature the host and guest must have matching page sizes. > + } > +out: > + mutex_unlock(&ioremap_guard_lock); > +} > + > +void iounmap_phys_range_hook(phys_addr_t phys_addr, size_t size) > +{ > + if (!static_branch_unlikely(&ioremap_guard_key)) > + return; > + > + VM_BUG_ON(phys_addr & ~PAGE_MASK || size & ~PAGE_MASK); > + > + mutex_lock(&ioremap_guard_lock); > + > + while (size) { > + u64 pfn = phys_addr >> PAGE_SHIFT; > + struct ioremap_guard_ref *ref; > + struct arm_smccc_res res; > + > + ref = xa_load(&ioremap_guard_array, pfn); > + if (!ref) { > + pr_warn_ratelimited("%llx not tracked, left mapped\n", > + phys_addr); > + goto next; > + } > + > + if (!refcount_dec_and_test(&ref->count)) > + goto next; > + > + xa_erase(&ioremap_guard_array, pfn); > + kfree(ref); > + > + arm_smccc_1_1_hvc(ARM_SMCCC_VENDOR_HYP_KVM_MMIO_GUARD_UNMAP_FUNC_ID, > + phys_addr, &res); > + if (res.a0 != SMCCC_RET_SUCCESS) { > + pr_warn_ratelimited("Failed to unregister %llx\n", > + phys_addr); > + goto out; > + } > + > + next: > + size -= PAGE_SIZE; > + phys_addr += PAGE_SIZE; > + } > +out: > + mutex_unlock(&ioremap_guard_lock); > +} > > static void __iomem *__ioremap_caller(phys_addr_t phys_addr, size_t size, > pgprot_t prot, void *caller) > -- > 2.30.2 > Thanks, drew _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel