From: Daniel Vetter <daniel@ffwll.ch>
To: Gerd Hoffmann <kraxel@redhat.com>
Cc: dri-devel <dri-devel@lists.freedesktop.org>,
"Christian König" <christian.koenig@amd.com>,
"Alex Deucher" <alexander.deucher@amd.com>,
"David Airlie" <airlied@linux.ie>,
"Maarten Lankhorst" <maarten.lankhorst@linux.intel.com>,
"Maxime Ripard" <mripard@kernel.org>,
"Thomas Zimmermann" <tzimmermann@suse.de>,
"Lucas Stach" <l.stach@pengutronix.de>,
"Russell King" <linux+etnaviv@armlinux.org.uk>,
"Christian Gmeiner" <christian.gmeiner@gmail.com>,
"Rob Clark" <robdclark@gmail.com>, "Sean Paul" <sean@poorly.run>,
"Ben Skeggs" <bskeggs@redhat.com>,
"Sandy Huang" <hjc@rock-chips.com>,
"Heiko Stübner" <heiko@sntech.de>,
"Thierry Reding" <thierry.reding@gmail.com>,
"Jonathan Hunter" <jonathanh@nvidia.com>,
"Oleksandr Andrushchenko" <oleksandr_andrushchenko@epam.com>,
"open list:RADEON and AMDGPU DRM DRIVERS"
<amd-gfx@lists.freedesktop.org>,
"open list" <linux-kernel@vger.kernel.org>,
"moderated list:DRM DRIVERS FOR VIVANTE GPU IP"
<etnaviv@lists.freedesktop.org>,
"open list:DRM DRIVER FOR MSM ADRENO GPU"
<linux-arm-msm@vger.kernel.org>,
"open list:DRM DRIVER FOR MSM ADRENO GPU"
<freedreno@lists.freedesktop.org>,
"open list:DRM DRIVER FOR NVIDIA GEFORCE/QUADRO GPUS"
<nouveau@lists.freedesktop.org>,
"moderated list:ARM/Rockchip SoC support"
<linux-arm-kernel@lists.infradead.org>,
"open list:ARM/Rockchip SoC support"
<linux-rockchip@lists.infradead.org>,
"open list:DRM DRIVERS FOR NVIDIA TEGRA"
<linux-tegra@vger.kernel.org>,
"moderated list:DRM DRIVERS FOR XEN"
<xen-devel@lists.xenproject.org>
Subject: Re: [PATCH v4 1/1] drm: allow limiting the scatter list size.
Date: Tue, 8 Sep 2020 13:37:12 +0200 [thread overview]
Message-ID: <20200908113712.GL2352366@phenom.ffwll.local> (raw)
In-Reply-To: <20200908100253.b22sff23737l77bo@sirius.home.kraxel.org>
On Tue, Sep 08, 2020 at 12:02:53PM +0200, Gerd Hoffmann wrote:
> > > > 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.
> >
> > The comment above vring_use_dma_api() suggests that this has not yet
> > happened, that's why I'm asking.
>
> Hmm, wading through the code, seems it indeed happen yet, even though my
> testing didn't show any issues. Probably pure luck because devices and
> cpus have the same memory view on x86. Guess I need to try this on
> ppc64 to see it actually failing ...
>
> So dropping the virtio_has_dma_quirk() checks isn't going to fly.
>
> Using dma_max_mapping_size() should be fine though. It might use a
> lower limit than needed for virtio, but it should not break things.
Makes sense. On this patch here:
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
And I guess would be good if virtio pushes a bit more towards using the
dma api abstraction fully so we can get rid of these hacks. Virtio feels
like a driver that really should be using dma-api and not dig around
behind it because "it' makes stuff 0.5% faster" or so, since being
virtualized it's already not the king of speed anyway :-)
Cheers, Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
prev parent reply other threads:[~2020-09-08 17:57 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20200907112425.15610-1-kraxel@redhat.com>
2020-09-07 11:24 ` [PATCH v4 1/1] drm: allow limiting the scatter list size Gerd Hoffmann
2020-09-07 13:53 ` Daniel Vetter
2020-09-08 5:48 ` Gerd Hoffmann
2020-09-08 8:55 ` Daniel Vetter
2020-09-08 10:02 ` Gerd Hoffmann
2020-09-08 11:37 ` Daniel Vetter [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20200908113712.GL2352366@phenom.ffwll.local \
--to=daniel@ffwll.ch \
--cc=airlied@linux.ie \
--cc=alexander.deucher@amd.com \
--cc=amd-gfx@lists.freedesktop.org \
--cc=bskeggs@redhat.com \
--cc=christian.gmeiner@gmail.com \
--cc=christian.koenig@amd.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=etnaviv@lists.freedesktop.org \
--cc=freedreno@lists.freedesktop.org \
--cc=heiko@sntech.de \
--cc=hjc@rock-chips.com \
--cc=jonathanh@nvidia.com \
--cc=kraxel@redhat.com \
--cc=l.stach@pengutronix.de \
--cc=linux+etnaviv@armlinux.org.uk \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-arm-msm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-rockchip@lists.infradead.org \
--cc=linux-tegra@vger.kernel.org \
--cc=maarten.lankhorst@linux.intel.com \
--cc=mripard@kernel.org \
--cc=nouveau@lists.freedesktop.org \
--cc=oleksandr_andrushchenko@epam.com \
--cc=robdclark@gmail.com \
--cc=sean@poorly.run \
--cc=thierry.reding@gmail.com \
--cc=tzimmermann@suse.de \
--cc=xen-devel@lists.xenproject.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox