Received: by 2002:a05:6358:bb9e:b0:b9:5105:a5b4 with SMTP id df30csp4858647rwb; Tue, 6 Sep 2022 14:01:57 -0700 (PDT) X-Google-Smtp-Source: AA6agR5A6rPhvxOqGAGj9CiaTfr1MTXIEquqcLR6FGkvHzA8ev08HQhpwd+RxCvPHJPkoBpwjP9b X-Received: by 2002:a17:906:fd8b:b0:770:7d4c:3486 with SMTP id xa11-20020a170906fd8b00b007707d4c3486mr234389ejb.518.1662498116981; Tue, 06 Sep 2022 14:01:56 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1662498116; cv=none; d=google.com; s=arc-20160816; b=C2BTwODOBzCkzZd/5lfvPbmZ7mJyazYZESnSF2esIV3vXMKKYGfidWTHKvhSSWMbAF sWMZGiGIDIbObo9Ro68+uVJ0YOJJcTcoZe4KPT+VJgS9D+WLlqNUDH93smapm6uXoYsE gF7H6L4E4mJhz261hXWLDy6nPok97CKZH7faaUILpgad9QKgh+PkSkT0D+i+r7tGS7pU cIQrOHi6UBO84Kll7QzXwTUhqtp5OYc/kqoMzE6TxJOqQDQL78tU2SD84DrgeSoJsF6J 5HpI3lmp1GC60NX5c+vAp3wPnFnmtjZCVhn6nDwsnlCmvtpjUP8mSDZUSzqX/JYRAdlb NZQA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-transfer-encoding :content-disposition:mime-version:references:mail-followup-to :message-id:subject:cc:to:from:date:dkim-signature; bh=O5EcAc3lvXGI4JQrr9YrLyEGo4R9/Yu+CBbQ8ensU3s=; b=uRFSywsxFSiM5UdiqVeRVRgja4EXPo1D3coeUV0BRgt9PQOO9BIiddUyKsffuliTty m8NR44UZ8i8Ss8OnhysTGjZfjV3QaD8IMSaZdo6X5flBKmgf9Ofq2T6ixQ7KhdCwmAYA AHimMu/j6yIAxoOj3yocwJIfqK8j9MsrGUGNV/LwY0kZO97dfPdWmQRFu/3Wfuu7Huu9 RNgqjQbmLB13RVnSVaMqJKZEtU4u/x2FQuMJKTzuoMEc51TfCjWuEazZYnH91rMamjSd InADUGaG4JRJo+YsHdVb/u0sSI9feZL1V+/yUliIKBghNEUXlneIe1iQcfur09/jQ53K 9i6w== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@ffwll.ch header.s=google header.b=OJjVDKh3; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id hz1-20020a1709072ce100b0073155c0e7cesi10421369ejc.677.2022.09.06.14.01.30; Tue, 06 Sep 2022 14:01:56 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@ffwll.ch header.s=google header.b=OJjVDKh3; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231152AbiIFUH0 (ORCPT + 99 others); Tue, 6 Sep 2022 16:07:26 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:57382 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231214AbiIFUHD (ORCPT ); Tue, 6 Sep 2022 16:07:03 -0400 Received: from mail-wm1-x329.google.com (mail-wm1-x329.google.com [IPv6:2a00:1450:4864:20::329]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id C6D90AA375 for ; Tue, 6 Sep 2022 13:02:29 -0700 (PDT) Received: by mail-wm1-x329.google.com with SMTP id h1so7443065wmd.3 for ; Tue, 06 Sep 2022 13:02:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ffwll.ch; s=google; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:references:mail-followup-to:message-id:subject:cc:to :from:date:from:to:cc:subject:date; bh=O5EcAc3lvXGI4JQrr9YrLyEGo4R9/Yu+CBbQ8ensU3s=; b=OJjVDKh3fcI/VQtO8L3fMXmkefvnaZ2TPXs4g3bDwXhiEMKG2tIGFa9WR1Rh+3uUBR zdGGM9Rmc74vfA+iORlSEN0n6yp66wZtNXZv0fPfYCTohNw3OZcMD+6dfcpdnPYyiwnh QoNnAEdgtugwvr2kaVFYcJT6RkBCn/qtM199k= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:references:mail-followup-to:message-id:subject:cc:to :from:date:x-gm-message-state:from:to:cc:subject:date; bh=O5EcAc3lvXGI4JQrr9YrLyEGo4R9/Yu+CBbQ8ensU3s=; b=ZkJmxQIeGE1+aj3zztfuSV9d7m4D/6Ues0YsAeJ06bIxFu/zaCJAG8075gK6cPY9bk AtkzGD3cH+hNk5pLORYdJVBDa1fLDrW7cnnPMXv/L8d3r5v8D/wfaEqDp31u6fBRQRLl WjO8j48DvAsbf6egODfEJLMSwAMtpAKjw9WbFcVrLBRfnwH6HZBZKL98H0zTKFS13Vdm ZmzCky4bUwBNRHvB6RivhvaukI2SQF45z2i3UL1bu6j+SAP3JwlJmvLGFrTk75jFfu2z 7obQpAo3pFxS8b7N7bHtCimcoswLNe62f6gkdWrx3s0AvJKT4gNAgtIuU5dNv5g/d/KL zg8A== X-Gm-Message-State: ACgBeo2Wmjh5M+EigQvUCw+UHdxMnRPJSt5/COt3NXgT2EAddPqLQKgN Z+2B2JaIokK7nuyhlTFtVS65Gg== X-Received: by 2002:a05:600c:34d2:b0:3a5:afe5:3eb5 with SMTP id d18-20020a05600c34d200b003a5afe53eb5mr14724108wmq.122.1662494510204; Tue, 06 Sep 2022 13:01:50 -0700 (PDT) Received: from phenom.ffwll.local (212-51-149-33.fiber7.init7.net. [212.51.149.33]) by smtp.gmail.com with ESMTPSA id y2-20020adfd082000000b0021d6924b777sm13896061wrh.115.2022.09.06.13.01.49 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 06 Sep 2022 13:01:49 -0700 (PDT) Date: Tue, 6 Sep 2022 22:01:47 +0200 From: Daniel Vetter To: Christian =?iso-8859-1?Q?K=F6nig?= Cc: Dmitry Osipenko , David Airlie , Huang Rui , Daniel Vetter , Trigger Huang , Gert Wollny , Antonio Caggiano , dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org, Dmitry Osipenko , kvm@vger.kernel.org, kernel@collabora.com, virtualization@lists.linux-foundation.org Subject: Re: [PATCH v1] drm/ttm: Refcount allocated tail pages Message-ID: Mail-Followup-To: Christian =?iso-8859-1?Q?K=F6nig?= , Dmitry Osipenko , David Airlie , Huang Rui , Trigger Huang , Gert Wollny , Antonio Caggiano , dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org, Dmitry Osipenko , kvm@vger.kernel.org, kernel@collabora.com, virtualization@lists.linux-foundation.org References: <20220815095423.11131-1-dmitry.osipenko@collabora.com> <8230a356-be38-f228-4a8e-95124e8e8db6@amd.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <8230a356-be38-f228-4a8e-95124e8e8db6@amd.com> X-Operating-System: Linux phenom 5.18.0-4-amd64 X-Spam-Status: No, score=-1.7 required=5.0 tests=BAYES_00,DKIM_INVALID, DKIM_SIGNED,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,T_SCC_BODY_TEXT_LINE, T_SPF_TEMPERROR autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Aug 15, 2022 at 12:05:19PM +0200, Christian K?nig wrote: > Am 15.08.22 um 11:54 schrieb Dmitry Osipenko: > > Higher order pages allocated using alloc_pages() aren't refcounted and they > > need to be refcounted, otherwise it's impossible to map them by KVM. This > > patch sets the refcount of the tail pages and fixes the KVM memory mapping > > faults. > > > > Without this change guest virgl driver can't map host buffers into guest > > and can't provide OpenGL 4.5 profile support to the guest. The host > > mappings are also needed for enabling the Venus driver using host GPU > > drivers that are utilizing TTM. > > > > Based on a patch proposed by Trigger Huang. > > Well I can't count how often I have repeated this: This is an absolutely > clear NAK! > > TTM pages are not reference counted in the first place and because of this > giving them to virgl is illegal. > > Please immediately stop this completely broken approach. We have discussed > this multiple times now. Yeah we need to get this stuff closed for real by tagging them all with VM_IO or VM_PFNMAP asap. It seems ot be a recurring amount of fun that people try to mmap dma-buf and then call get_user_pages on them. Which just doesn't work. I guess this is also why Rob Clark send out that dma-buf patch to expos mapping information (i.e. wc vs wb vs uncached). There seems to be some serious bonghits going on :-/ -Daniel > > Regards, > Christian. > > > > > Cc: stable@vger.kernel.org > > Cc: Trigger Huang > > Link: https://www.collabora.com/news-and-blog/blog/2021/11/26/venus-on-qemu-enabling-new-virtual-vulkan-driver/#qcom1343 > > Tested-by: Dmitry Osipenko # AMDGPU (Qemu and crosvm) > > Signed-off-by: Dmitry Osipenko > > --- > > drivers/gpu/drm/ttm/ttm_pool.c | 25 ++++++++++++++++++++++++- > > 1 file changed, 24 insertions(+), 1 deletion(-) > > > > diff --git a/drivers/gpu/drm/ttm/ttm_pool.c b/drivers/gpu/drm/ttm/ttm_pool.c > > index 21b61631f73a..11e92bb149c9 100644 > > --- a/drivers/gpu/drm/ttm/ttm_pool.c > > +++ b/drivers/gpu/drm/ttm/ttm_pool.c > > @@ -81,6 +81,7 @@ static struct page *ttm_pool_alloc_page(struct ttm_pool *pool, gfp_t gfp_flags, > > unsigned long attr = DMA_ATTR_FORCE_CONTIGUOUS; > > struct ttm_pool_dma *dma; > > struct page *p; > > + unsigned int i; > > void *vaddr; > > /* Don't set the __GFP_COMP flag for higher order allocations. > > @@ -93,8 +94,10 @@ static struct page *ttm_pool_alloc_page(struct ttm_pool *pool, gfp_t gfp_flags, > > if (!pool->use_dma_alloc) { > > p = alloc_pages(gfp_flags, order); > > - if (p) > > + if (p) { > > p->private = order; > > + goto ref_tail_pages; > > + } > > return p; > > } > > @@ -120,6 +123,23 @@ static struct page *ttm_pool_alloc_page(struct ttm_pool *pool, gfp_t gfp_flags, > > dma->vaddr = (unsigned long)vaddr | order; > > p->private = (unsigned long)dma; > > + > > +ref_tail_pages: > > + /* > > + * KVM requires mapped tail pages to be refcounted because put_page() > > + * is invoked on them in the end of the page fault handling, and thus, > > + * tail pages need to be protected from the premature releasing. > > + * In fact, KVM page fault handler refuses to map tail pages to guest > > + * if they aren't refcounted because hva_to_pfn_remapped() checks the > > + * refcount specifically for this case. > > + * > > + * In particular, unreferenced tail pages result in a KVM "Bad address" > > + * failure for VMMs that use VirtIO-GPU when guest's Mesa VirGL driver > > + * accesses mapped host TTM buffer that contains tail pages. > > + */ > > + for (i = 1; i < 1 << order; i++) > > + page_ref_inc(p + i); > > + > > return p; > > error_free: > > @@ -133,6 +153,7 @@ static void ttm_pool_free_page(struct ttm_pool *pool, enum ttm_caching caching, > > { > > unsigned long attr = DMA_ATTR_FORCE_CONTIGUOUS; > > struct ttm_pool_dma *dma; > > + unsigned int i; > > void *vaddr; > > #ifdef CONFIG_X86 > > @@ -142,6 +163,8 @@ static void ttm_pool_free_page(struct ttm_pool *pool, enum ttm_caching caching, > > if (caching != ttm_cached && !PageHighMem(p)) > > set_pages_wb(p, 1 << order); > > #endif > > + for (i = 1; i < 1 << order; i++) > > + page_ref_dec(p + i); > > if (!pool || !pool->use_dma_alloc) { > > __free_pages(p, order); > -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch