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 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 smtp.lore.kernel.org (Postfix) with ESMTPS id EC675C05027 for ; Mon, 6 Feb 2023 12:14:17 +0000 (UTC) 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=1es6KAHzWnvdc1O6pXlvfqDfLWvdrlkHPAjkj6WBHA8=; b=VjIISe2b2Emboa c6fhQX+bXma9IhAZTy63Ikff9bxbyf+U/IBsVDmXS82wWWKkWkh7dtnnvH9zchbuLbnWVx87S5mk4 m3mBSXDbJkN8ykiwiRBQtutVd6n3ljmqw77XVELajWs/Ss+SqfSOozgWvhk80Uz0L1xg4B4wq+KFC +1xuKBn49XmIJwlMhmRGrFoMxaO7NciOVaz7XYRIav+CK2bOTrjhFhtJ+pTMTD9zT4u1qy7fUjmLe jkmyJPJZutEvTIFxpR1aAHyKvQtS/Q4bGpMVxWugRCSc1nnCiYAYdvDs0nNb8g9wu+wvLi334I0h4 Jw1zWQNrYI2czdGgg9Cw==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1pP0N0-008SXE-Ph; Mon, 06 Feb 2023 12:13:14 +0000 Received: from mail-wm1-x335.google.com ([2a00:1450:4864:20::335]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1pP0Mx-008SVV-4w for linux-arm-kernel@lists.infradead.org; Mon, 06 Feb 2023 12:13:12 +0000 Received: by mail-wm1-x335.google.com with SMTP id f47-20020a05600c492f00b003dc584a7b7eso10599126wmp.3 for ; Mon, 06 Feb 2023 04:13:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=J1IvvUpDIzzYw9+SRNx7DbUaJMMIkgO4bGezDC/TRRk=; b=b9OkVp+ugc2CmhJ15afKzlOpT+3SRO44IWMEshIv0enrSHBX0zZM02taZhrrTXBGD0 C1WNzpxCvqbJ3meK0TWN/TM8jVlXSEppAnVjaOdVUh416Gxb+VBZAotdedGmMl0azU8e eJIJmOD+cITKYv0FIDRebS6EkjlSaeuK5xERVgL+DFPU6Qx0nR35Il/f5GZHRTm+nmcl jMy/xdavGAJ5rkH2d12gXatxrkYw/oYJyxi0RCrOS7dQ0qeO0xOV+h1QECREqbkpgWM7 yoVM2P/6cfgVrXOK7RzASli2s5+RZs76TtGne3z96on2dhbN2ydXomwz6fU1668+OZEP 8Erg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=J1IvvUpDIzzYw9+SRNx7DbUaJMMIkgO4bGezDC/TRRk=; b=ISThVfhQz1OjET8dvJ6Y9utZ1fSMSEEIk+BVyJuBoeXTjCnE53CrU2iQd1Li6PIVdl x/eWdr5GEfvZE129LHEvYMZUqpf4OzSDpEuScmK/bs3MZO3NGUmUgUfo0kAm8RibJRCK 1/LXZhaSS0cFm7dm6cj2+tj28k0L2eR1dDH1lBMHpmqMEFSoHyvsuGJmxFVPKKQ7lODy 3VbezVATcTEZTWgqC+yibYo+VhJlYvoycHKJF9LUTphiSwh/Jq28ZwPZh6wbA5BZ5sbz yz+LgMNL9OaJvXxqGSrxs2N7mCmhHbDPYEq0irajmz7cMzMZOkC3uawtERj7ra/tYjn4 LxFA== X-Gm-Message-State: AO0yUKW25p254Sfzb2Wu+XwNWvx7yEudskMhSXSyO1woNPdcYhnY2di4 SvIfCNryG5mH2u87wG0SHQJ76Q== X-Google-Smtp-Source: AK7set/X5OiGOGu17xeNlsq0wM6jY6K95NiKkD8/6IxChYVhakslSCvpz9hv/BN5iLVW9r32RGXpYg== X-Received: by 2002:a05:600c:3849:b0:3d5:365b:773e with SMTP id s9-20020a05600c384900b003d5365b773emr20472104wmr.39.1675685589158; Mon, 06 Feb 2023 04:13:09 -0800 (PST) Received: from myrica (054592b0.skybroadband.com. [5.69.146.176]) by smtp.gmail.com with ESMTPSA id l20-20020a05600c089400b003dc41a9836esm10542456wmp.43.2023.02.06.04.13.08 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 06 Feb 2023 04:13:08 -0800 (PST) Date: Mon, 6 Feb 2023 12:13:05 +0000 From: Jean-Philippe Brucker To: "tina.zhang" Cc: maz@kernel.org, catalin.marinas@arm.com, will@kernel.org, joro@8bytes.org, robin.murphy@arm.com, james.morse@arm.com, suzuki.poulose@arm.com, oliver.upton@linux.dev, yuzenghui@huawei.com, smostafa@google.com, dbrazdil@google.com, ryan.roberts@arm.com, linux-arm-kernel@lists.infradead.org, kvmarm@lists.linux.dev, iommu@lists.linux.dev Subject: Re: [RFC PATCH 15/45] KVM: arm64: pkvm: Add __pkvm_host_share/unshare_dma() Message-ID: References: <20230201125328.2186498-1-jean-philippe@linaro.org> <20230201125328.2186498-16-jean-philippe@linaro.org> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20230206_041311_313271_2D83A337 X-CRM114-Status: GOOD ( 19.79 ) 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 Hi Tina, On Sat, Feb 04, 2023 at 08:51:38PM +0800, tina.zhang wrote: > > +int __pkvm_host_share_dma(phys_addr_t phys_addr, size_t size, bool is_ram) > > +{ > > + int i; > > + int ret; > > + size_t nr_pages = size >> PAGE_SHIFT; > > + > > + if (WARN_ON(!PAGE_ALIGNED(phys_addr | size))) > > + return -EINVAL; > > + > > + host_lock_component(); > > + hyp_lock_component(); > > + > > + for (i = 0; i < nr_pages; i++) { > > + ret = __pkvm_host_share_dma_page(phys_addr + i * PAGE_SIZE, > > + is_ram); > Hi Jean, > > I'm not familiar with ARM arch. Just out of curiosity. If pKVM-ARM populates > the host stage-2 page table lazily, would there be a case that device driver > in host triggers DMA with pages which have not been mapped to the host > stage-2 page table yet? How do we handle this situation? It's possible that the host asks the hypervisor to map on the IOMMU side a page that is not yet mapped on the CPU side. In general before calling map_pages() the host zero-initializes the page, triggering a page fault which creates the mapping, so this case is rare. But if it happens, __pkvm_host_share_dma() will create the CPU stage-2 mapping: __pkvm_host_share_dma() do_share() host_initiate_share() host_stage2_idmap_locked() which creates a valid identity mapping, along with the ownership information PVKM_PAGE_SHARED_OWNED. That ownership info is really all we need here, to prevent future donations to guests or hyp. Since the SMMU side uses separate stage-2 page tables, we don't actually need to create a valid mapping on the CPU side yet, that's just how pKVM's mem_protect currently works. But I don't think it hurts to create the mapping right away instead of waiting for the CPU page fault, because the host will likely access the page soon to read what the device wrote there. Thanks, Jean _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel