Received: by 2002:a05:6a10:2785:0:0:0:0 with SMTP id ia5csp3043379pxb; Tue, 12 Jan 2021 05:06:49 -0800 (PST) X-Google-Smtp-Source: ABdhPJxtQ6QAywbfLO2IxIAw+eb5S26ttxYLAKlXq6KD9Ymd+lI1JCZimfpm2VbO6ZcyvCA09Gsf X-Received: by 2002:a17:906:6053:: with SMTP id p19mr3204433ejj.93.1610456808985; Tue, 12 Jan 2021 05:06:48 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1610456808; cv=none; d=google.com; s=arc-20160816; b=a62RIVhkL5vAAKtWgGX5PyByykbpeQaQWoVMm5TX5++2fkSeoQfYSr2blQWik89Auo jUvrSQXymRxeZDMHT8HEiAJbwOxN1Ye7Qis7HSpDxWaWwF78wl5Dv3F3Nsp9bh+lI4a3 GRdRGI0y0m2FERdVvdUxMjb7hxuY268zpQ9by0NK/bYTuTpkjEY6cRhD/0WK/073XZUA 4ETcuiNqYIH8KbBt57LQSXxSHXqxY8iSD209afJ6KQ7oLs5DBy6Dlsq3f0xON+qvQibG aCc9IyJwpuaUkxbNSWvPTYUbbY3zgpHyGWKHLV7XVhvNFuv3JruMgYduJfFGKo9u5KNj gxPw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:in-reply-to :mime-version:user-agent:date:message-id:from:cc:references:to :subject; bh=/iREcEqHQy9USyYGM8SJUa1WH6aMmx2f6f1GnIr5qqM=; b=hscZNrxnG4Tqfrr8D9JZwUK28bz+XQlqp1ZKCIJj5BpEV/5635jiicL7ZHaRJTTbRU Yolb4lHlnIuPxlah7mR80F1cr7Sxlei7PvMLJnhabGfZ1IA9igs/7FZ1c2nvges3b4Q6 Se63qlyqTvF1C6TgECYu85SIBhBEYbS97J/JRVsfx56/2MmbWnnMfQ8KLJQSvjlkGbko Koq4pdEkWuGo0dr+KU/wIaQFL6spYdAUbLo2k0z6Jk66abDNuXvXiwCq+b4q39B8/HPx xfLWy62bYH9IFgyVyU0TOAd9vKThiqcQELrtC7UZjVIyDzmx0es7HoIL94b1tWmhO3tp +0Sw== ARC-Authentication-Results: i=1; mx.google.com; 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 Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id bu13si1082978ejb.588.2021.01.12.05.06.24; Tue, 12 Jan 2021 05:06:48 -0800 (PST) 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; 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 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1732077AbhALMFc (ORCPT + 99 others); Tue, 12 Jan 2021 07:05:32 -0500 Received: from szxga04-in.huawei.com ([45.249.212.190]:10713 "EHLO szxga04-in.huawei.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727952AbhALMFb (ORCPT ); Tue, 12 Jan 2021 07:05:31 -0500 Received: from DGGEMS410-HUB.china.huawei.com (unknown [172.30.72.58]) by szxga04-in.huawei.com (SkyGuard) with ESMTP id 4DFTkD0LGDzl46q; Tue, 12 Jan 2021 20:03:32 +0800 (CST) Received: from [10.174.184.42] (10.174.184.42) by DGGEMS410-HUB.china.huawei.com (10.3.19.210) with Microsoft SMTP Server id 14.3.498.0; Tue, 12 Jan 2021 20:04:39 +0800 Subject: Re: [PATCH 4/5] vfio/iommu_type1: Carefully use unmap_unpin_all during dirty tracking To: Alex Williamson References: <20210107092901.19712-1-zhukeqian1@huawei.com> <20210107092901.19712-5-zhukeqian1@huawei.com> <20210111144913.3092b1b1@omen.home.shazbot.org> CC: , , , , , Kirti Wankhede , Cornelia Huck , Will Deacon , "Marc Zyngier" , Catalin Marinas , "Mark Rutland" , James Morse , "Robin Murphy" , Joerg Roedel , Daniel Lezcano , Thomas Gleixner , "Suzuki K Poulose" , Julien Thierry , Andrew Morton , Alexios Zavras , , From: Keqian Zhu Message-ID: <198f0afd-343a-9fbc-9556-95670ca76a2c@huawei.com> Date: Tue, 12 Jan 2021 20:04:38 +0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 In-Reply-To: <20210111144913.3092b1b1@omen.home.shazbot.org> Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: 7bit X-Originating-IP: [10.174.184.42] X-CFilter-Loop: Reflected Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 2021/1/12 5:49, Alex Williamson wrote: > On Thu, 7 Jan 2021 17:29:00 +0800 > Keqian Zhu wrote: > >> If we detach group during dirty page tracking, we shouldn't remove >> vfio_dma, because dirty log will lose. >> >> But we don't prevent unmap_unpin_all in vfio_iommu_release, because >> under normal procedure, dirty tracking has been stopped. > > This looks like it's creating a larger problem than it's fixing, it's > not our job to maintain the dirty bitmap regardless of what the user > does. If the user detaches the last group in a container causing the > mappings within that container to be deconstructed before the user has > collected dirty pages, that sounds like a user error. A container with > no groups is de-privileged and therefore loses all state. Thanks, > > Alex Hi Alex, This looks good to me ;-). That's a reasonable constraint for user behavior. What about replacing this patch with an addition to the uapi document of VFIO_GROUP_UNSET_CONTAINER? User should pay attention to this when call this ioctl during dirty tracking. And any comments on other patches? thanks. Thanks. Keqian > >> Fixes: d6a4c185660c ("vfio iommu: Implementation of ioctl for dirty pages tracking") >> Signed-off-by: Keqian Zhu >> --- >> drivers/vfio/vfio_iommu_type1.c | 14 ++++++++++++-- >> 1 file changed, 12 insertions(+), 2 deletions(-) >> >> diff --git a/drivers/vfio/vfio_iommu_type1.c b/drivers/vfio/vfio_iommu_type1.c >> index 26b7eb2a5cfc..9776a059904d 100644 >> --- a/drivers/vfio/vfio_iommu_type1.c >> +++ b/drivers/vfio/vfio_iommu_type1.c >> @@ -2373,7 +2373,12 @@ static void vfio_iommu_type1_detach_group(void *iommu_data, >> if (list_empty(&iommu->external_domain->group_list)) { >> vfio_sanity_check_pfn_list(iommu); >> >> - if (!IS_IOMMU_CAP_DOMAIN_IN_CONTAINER(iommu)) >> + /* >> + * During dirty page tracking, we can't remove >> + * vfio_dma because dirty log will lose. >> + */ >> + if (!IS_IOMMU_CAP_DOMAIN_IN_CONTAINER(iommu) && >> + !iommu->dirty_page_tracking) >> vfio_iommu_unmap_unpin_all(iommu); >> >> kfree(iommu->external_domain); >> @@ -2406,10 +2411,15 @@ static void vfio_iommu_type1_detach_group(void *iommu_data, >> * iommu and external domain doesn't exist, then all the >> * mappings go away too. If it's the last domain with iommu and >> * external domain exist, update accounting >> + * >> + * Note: During dirty page tracking, we can't remove vfio_dma >> + * because dirty log will lose. Just update accounting is a good >> + * choice. >> */ >> if (list_empty(&domain->group_list)) { >> if (list_is_singular(&iommu->domain_list)) { >> - if (!iommu->external_domain) >> + if (!iommu->external_domain && >> + !iommu->dirty_page_tracking) >> vfio_iommu_unmap_unpin_all(iommu); >> else >> vfio_iommu_unmap_unpin_reaccount(iommu); > > . >