From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-ed1-f52.google.com (mail-ed1-f52.google.com [209.85.208.52]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id C3952437132 for ; Wed, 5 Aug 2026 15:26:16 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.208.52 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785943588; cv=none; b=ngahtJLhu0SKoeDXqUa/Xb0xEbcWR8iC+1DTY6yCPsk3i2s4qJQPlmOxxDx4T8I/234Dxp8diTfTaX0EiRhO6+mL5aszqk/MqcT9AA60quzT10WtXjcUXCseMekUbIgO6AJRAH0iw4/lzA8gvxGjtmikd36k2bfvyDCBoOJu8/0= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785943588; c=relaxed/simple; bh=k2dfPXeOzAHpRioWn2Z8dsyVF7DcClGaHxC6ZjFMKf0=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=vDYbv4oIiSMKzz3c+9tA+nIA9ygJlERkhsLnBZczdHuBECRgXgYCe1qmFaExQRa05tSggs7E15PgOEoc37TtzIKrgb7zL/WG++PU/r6idsyZD8VmqZu056fNcAKO+0wVIKfsMBNJKxiYf11F2cM4z9MLnvmPVbmitXOJgSeXJqE= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com; spf=pass smtp.mailfrom=google.com; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b=aUTAve+c; arc=none smtp.client-ip=209.85.208.52 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=google.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="aUTAve+c" Received: by mail-ed1-f52.google.com with SMTP id 4fb4d7f45d1cf-6a177b2dc8dso9692a12.0 for ; Wed, 05 Aug 2026 08:26:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20251104; t=1785943572; x=1786548372; darn=vger.kernel.org; h=in-reply-to:content-disposition:content-type:mime-version :references:message-id:subject:cc:to:from:date:from:to:cc:subject :date:message-id:reply-to:content-type; bh=hNRmrl2B/brOKHnxIA/lHQtuwZlyNTPIK3U8kLKpdDc=; b=aUTAve+cvkz99v+qJx1BwvbbEgPaAt44EYNPkA+tFprcvdSt5BEqkblBu8urPCq/yy qiOq+uOZg3jFXkPgGvEDbK2vzw/rTzfqdmGgXFaKhgjLAk2MPN0EfH+BSXWBtt4RIabL hxbv4Wo9rnbQCnS6l7kI5A+Kacy6z4yn90dwH29HfIbntegsuvwVUI0DRk+0tvmeZzhq tdk1ZQaNizpS/CAoDs6UYYN9/4irVxO4FPyVxfc9L9PbkXhTigUx6U8UXkGktrV+PN+r 7xS24cf23wjZ0JVYgIsfZ6Mzhkrg2y5RS57+KawFKDCswH8sKzaE0yRtKRBjFpXNEzwq x9oA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1785943572; x=1786548372; h=in-reply-to:content-disposition:content-type:mime-version :references:message-id:subject:cc:to:from:date:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to :content-type; bh=hNRmrl2B/brOKHnxIA/lHQtuwZlyNTPIK3U8kLKpdDc=; b=T4+FgL30KP6updX5y0xGM4AlrfXGcQwJdmqCt1DGy6AKrrObsfJjwAB+Y+rH4mDZhh Bu2Hn2V8pbYZz+fOjHr5fUtwuYygADNe441Hls0R6bHPsJyyEHRtEzTVR70nlQq2+ido Cjkyp99R1gDzPdL4X6j9f48iatRvu3lJGSx9i1zAuQmti2Yh+mC8e5inJgiSn+Z+xs3c GGPH7vBl5GqqKPo2Cf7qhezfDJieI80gwu9LGPLe1FpVWO8aiK9TVtgjIWqv05T1zqgQ dUOS+gPCCLb/csv2+ZMhZR6+L/XBkmCcoW6w6ApcqTIEfM1oD4cGhlElSOhPYyG5MzdY RwJg== X-Forwarded-Encrypted: i=1; AHgh+RpXdjekpAGMfWJIB1yQfrcpC0vDPt7NPk9HCdUe32Iq4Rxp6NL2LL4HTnR2iAMjv52QuwxTBhKKni6FAu0=@vger.kernel.org X-Gm-Message-State: AOJu0YycSXlMJXkuLDMNo9aQrfE7uCc4xM+EnMjXwYyOv+hEaQLWwHSr XYBbGy2w+V2zznJ54z/PyEZ8ifwaRthoWiV3Hlup+LX3WzMJXyp8MxxCWfwmXp66DQ== X-Gm-Gg: AR+sD12GdWggepnR3yJbj4by1qbRw5ZyyC5bhE6mbQXrxfPRFR0rr76VptPB98dK6fu B86Gt/O/Nz9GLGuh+J0T58s+ggVrJR8ZJD0LuWfq47CJk4xEzvNapGSQ/BIrcgFUjqGZ7sNGyPC l1NOCE44CvvAe/1KQq/CDj1D93MnoTh4eZJzJGxe3BFGGIMmNyrDQlxNAlSBknGyMJ0Usyy3DLs Sn75rBu1r6C/avuC/ab75xlzGozDLvXPoWHTnUjeXAo6wAC6tCXLTV3qjADe0XbvINhVD89whop EtV9ZuAjE90vm4b0F8VKc1jqIqRegy0IFe/k0iJGXPT5DKbsUSDkGr2KgpOfAvX3wpAdlL7MDoL ihzJ8tfI04wuOZ3JtyR4eLoXO6Z9sfkLglmjPUSfHSUBrkBbssAwpLNYEOVzA5u+jqfR0whCary PY1vUqW/CMy2NtuXiwMKAOfC/Lsr8zLvxnREtPHeOKrV6+lUomYLd9IkfU5fLPX4m8AfjkYSRr9 EWKI9w0bwmmf/VUXFRF6f33k8vZPg== X-Received: by 2002:a05:6402:44c8:b0:697:7f69:48e3 with SMTP id 4fb4d7f45d1cf-6a14fc7db15mr77076a12.10.1785943571545; Wed, 05 Aug 2026 08:26:11 -0700 (PDT) Received: from google.com (250.192.189.35.bc.googleusercontent.com. [35.189.192.250]) by smtp.gmail.com with ESMTPSA id 4fb4d7f45d1cf-6a17c55aa21sm1309954a12.21.2026.08.05.08.26.10 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 05 Aug 2026 08:26:10 -0700 (PDT) Date: Wed, 5 Aug 2026 15:26:06 +0000 From: Mostafa Saleh To: Sebastian Ene Cc: linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, kvmarm@lists.linux.dev, iommu@lists.linux.dev, catalin.marinas@arm.com, will@kernel.org, maz@kernel.org, oliver.upton@linux.dev, joey.gouly@arm.com, suzuki.poulose@arm.com, yuzenghui@huawei.com, joro@8bytes.org, jgg@ziepe.ca, mark.rutland@arm.com, qperret@google.com, tabba@google.com, vdonnefort@google.com, keirf@google.com Subject: Re: [PATCH v7 02/24] KVM: arm64: Donate MMIO to the hypervisor Message-ID: References: <20260715115906.2664882-1-smostafa@google.com> <20260715115906.2664882-3-smostafa@google.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: On Wed, Aug 05, 2026 at 02:57:02PM +0000, Sebastian Ene wrote: > > > > + KVM_HOST_INVALID_PTE_TYPE_DONATION, > > > > + FIELD_PREP(KVM_HOST_DONATION_PTE_OWNER_MASK, PKVM_ID_HYP)); > > > > +unlock: > > > > + host_unlock_component(); > > > > + return ret; > > > > +} > > > > + > > > > +int __pkvm_hyp_donate_host_mmio(phys_addr_t addr, size_t size) > > > > > > This function seems to only update the host stage-2 annotation but it > > > doesn't destroy the hyp mapping. > > > > Yes, as mentioned above there is no way to destroy it, and this was > > not desgined for frequent use. Typicaly, __pkvm_host_donate_hyp_mmio() > > is called at boot per area/device. And __pkvm_hyp_donate_host_mmio() > > is only used for failures. > > > > Yes, I saw that you only allow the call during the init pKVM calls, however it seems a bit fragile. Why is it fragile? Nothing is wrong with leaking private mapping it's not real memory and it's massive, and given that this shouldn't happen and will cause KVM to fail on the system, it is not that bad. (as mentioned all other callers do the same) > > > > > > > I was looking to make use of this patch in an upcoming posting for the > > > v2 ITS hardening but in my case I don't need the private VA range > > > creation. > > > > I believe if you need to map MMIO, private range is the right way to > > do it as the linear map was mainly designed around system memory. > > Is there a reason behind not having MMIO as part of the linear > map in the hypervisor ? I would like to avoid holding the hva around and > just do a simple addition to resolve the hyp_va. When the linear is created it only considers the system memory layout https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/arm64/kvm/va_layout.c#n82 Which means that on some systems an MMIO address can be larger than the linear map. There is another comment about tha also in: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/arm64/kvm/hyp/nvhe/mm.c#n420 Thanks, Mostafa > > > > > Thanks, > > Mostafa > > > > Thanks, > Sebastian