Received: by 2002:a05:6a10:22f:0:0:0:0 with SMTP id 15csp3689838pxk; Mon, 7 Sep 2020 22:51:12 -0700 (PDT) X-Google-Smtp-Source: ABdhPJyyyWzK4O1LXjENPRGuetmwrtC4lnPaZBzkClfbxWY0EjtF6xx1xvveJciOJDNIIfQLDlMb X-Received: by 2002:a05:6402:1b1d:: with SMTP id by29mr24763221edb.96.1599544271966; Mon, 07 Sep 2020 22:51:11 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1599544271; cv=none; d=google.com; s=arc-20160816; b=yclSFssZIiV534bkM0A5pfWXa2ZIAeKXk7KMHyqJ3cWML1t0qkOs1fGwnppDKI9c2V A8RNgRUEA72OZDucqKE6B66kbQnyZGFD6qRiyL84P9ZvQ2/57kruznvlA2uaLYLmUXQQ P78ZlmmicHF4E0wDlVf7fOUQztz6ODTmQlrjoFPr5pXNFtGxR74srkgvw3pAtD/MYqYD Q52NjnrWo1IFnWzhAl0bNv/RhbDvqNKR/LHHlHa8aIrgh5v040mX1c4wP+yOdB16TxmZ uATS8AZMWPTrCOy9tTktd8Jiq7GytJddVUN9YgCY2m/sM6cN7K+1n3jFJi91dwl2mh5d 7hXA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:in-reply-to:content-disposition :mime-version:references:message-id:subject:cc:to:from:date :dkim-signature; bh=eQK1NPwmSWOx8INcFCnwK3inQ46y12Ng6QHkYnvGe3I=; b=eq8yxFXbxNHuMpEL2/3Nc1T1OeLNd7pDk4eRUwcD/Y5rpnqZmR5DVL+cpf0ZW0GLNp NscCBkhsoW2pVcrU7e9dFJ0sFqyB2kG6BMy4gaR4yhCu+f9TGYeP6Ic4wE3a1h7e9B2n LQCfrbJ3cOBkXYvfdGXw7ZR7OOMPQSDdVKMnlRgnvW8mCpaV/gtQGDo9D53IitQaK2Ha wPa6RpOVwfJoE1tAdHirx59Uj1qq5x1GWe11jw0cgOmBTLFkX3WXkwjIRNA9TXXVEPsT k2+GkIG6NZqYwG+GLQ1o/T/hyVOUg9B7g3UKeVxbxUF7vULuTsecAQPvo/1nCWcj0uRO hywg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=LgEG1tI4; 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; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id v11si11111660eju.488.2020.09.07.22.50.49; Mon, 07 Sep 2020 22:51:11 -0700 (PDT) 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; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=LgEG1tI4; 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; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728740AbgIHFtP (ORCPT + 99 others); Tue, 8 Sep 2020 01:49:15 -0400 Received: from us-smtp-delivery-124.mimecast.com ([216.205.24.124]:30795 "EHLO us-smtp-delivery-124.mimecast.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728680AbgIHFtN (ORCPT ); Tue, 8 Sep 2020 01:49:13 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1599544151; 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=eQK1NPwmSWOx8INcFCnwK3inQ46y12Ng6QHkYnvGe3I=; b=LgEG1tI4Zg9p7W0XFQUtFbSA9O19wnmfYk+arU225fe071UZkhTYVyVe9ozIFm6qvgBL9I vFqaZ1bni8u1ptDth7cpUSare4TzzO1Eooo+g3VHSu5At+2xYJObBSk4R3HVt+MsB1AHm0 QghfE8aBXYJwxDxqzIyjUC/Dz9jvjKg= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-45-r-VulFGYMA-fjnnBfjljEg-1; Tue, 08 Sep 2020 01:49:07 -0400 X-MC-Unique: r-VulFGYMA-fjnnBfjljEg-1 Received: from smtp.corp.redhat.com (int-mx05.intmail.prod.int.phx2.redhat.com [10.5.11.15]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id E448D425D1; Tue, 8 Sep 2020 05:49:02 +0000 (UTC) Received: from sirius.home.kraxel.org (ovpn-112-56.ams2.redhat.com [10.36.112.56]) by smtp.corp.redhat.com (Postfix) with ESMTP id 2C936811BE; Tue, 8 Sep 2020 05:48:58 +0000 (UTC) Received: by sirius.home.kraxel.org (Postfix, from userid 1000) id 0FDF617538; Tue, 8 Sep 2020 07:48:58 +0200 (CEST) Date: Tue, 8 Sep 2020 07:48:58 +0200 From: Gerd Hoffmann To: Daniel Vetter Cc: dri-devel , Christian =?utf-8?B?S8O2bmln?= , Alex Deucher , David Airlie , Maarten Lankhorst , Maxime Ripard , Thomas Zimmermann , Lucas Stach , Russell King , Christian Gmeiner , Rob Clark , Sean Paul , Ben Skeggs , Sandy Huang , Heiko =?utf-8?Q?St=C3=BCbner?= , Thierry Reding , Jonathan Hunter , Oleksandr Andrushchenko , "open list:RADEON and AMDGPU DRM DRIVERS" , open list , "moderated list:DRM DRIVERS FOR VIVANTE GPU IP" , "open list:DRM DRIVER FOR MSM ADRENO GPU" , "open list:DRM DRIVER FOR MSM ADRENO GPU" , "open list:DRM DRIVER FOR NVIDIA GEFORCE/QUADRO GPUS" , "moderated list:ARM/Rockchip SoC support" , "open list:ARM/Rockchip SoC support" , "open list:DRM DRIVERS FOR NVIDIA TEGRA" , "moderated list:DRM DRIVERS FOR XEN" Subject: Re: [PATCH v4 1/1] drm: allow limiting the scatter list size. Message-ID: <20200908054858.um34wojjv6uhi7d3@sirius.home.kraxel.org> References: <20200907112425.15610-1-kraxel@redhat.com> <20200907112425.15610-2-kraxel@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Scanned-By: MIMEDefang 2.79 on 10.5.11.15 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Sep 07, 2020 at 03:53:02PM +0200, Daniel Vetter wrote: > On Mon, Sep 7, 2020 at 1:24 PM Gerd Hoffmann wrote: > > > > Add drm_device argument to drm_prime_pages_to_sg(), so we can > > call dma_max_mapping_size() to figure the segment size limit > > and call into __sg_alloc_table_from_pages() with the correct > > limit. > > > > This fixes virtio-gpu with sev. Possibly it'll fix other bugs > > too given that drm seems to totaly ignore segment size limits > > so far ... > > > > v2: place max_segment in drm driver not gem object. > > v3: move max_segment next to the other gem fields. > > v4: just use dma_max_mapping_size(). > > > > Signed-off-by: Gerd Hoffmann > > Uh, are you sure this works in all cases for virtio? Sure, I've tested it ;) > The comments I've found suggest very much not ... Or is that all very > old stuff only that no one cares about anymore? I think these days it is possible to override dma_ops per device, which in turn allows virtio to deal with the quirks without the rest of the kernel knowing about these details. I also think virtio-gpu can drop the virtio_has_dma_quirk() checks, just use the dma api path unconditionally and depend on virtio core having setup dma_ops in a way that it JustWorks[tm]. I'll look into that next. take care, Gerd