From: Christoph Hellwig <hch@lst.de>
To: "Christian König" <christian.koenig@amd.com>
Cc: amd-gfx@lists.freedesktop.org,
Thomas Zimmermann <tzimmermann@suse.de>,
David Airlie <airlied@linux.ie>,
Roland Scheidegger <sroland@vmware.com>,
dri-devel@lists.freedesktop.org,
Maarten Lankhorst <maarten.lankhorst@linux.intel.com>,
Maxime Ripard <mripard@kernel.org>,
virtualization@lists.linux-foundation.org,
iommu@lists.linux-foundation.org, Huang Rui <ray.huang@amd.com>,
VMware Graphics <linux-graphics-maintainer@vmware.com>,
Ben Skeggs <bskeggs@redhat.com>, Daniel Vetter <daniel@ffwll.ch>,
nouveau@lists.freedesktop.org,
Alex Deucher <alexander.deucher@amd.com>,
Dave Airlie <airlied@redhat.com>,
spice-devel@lists.freedesktop.org, Christoph Hellwig <hch@lst.de>,
Zack Rusin <zackr@vmware.com>
Subject: Re: [PATCH] drm/ttm: use dma_alloc_pages for the page pool
Date: Tue, 11 May 2021 10:50:11 +0200 [thread overview]
Message-ID: <20210511085011.GA14477@lst.de> (raw)
In-Reply-To: <d2a72848-8273-d0b6-0250-3fe88122246a@amd.com>
On Tue, May 11, 2021 at 09:35:20AM +0200, Christian König wrote:
> We certainly going to need the drm_need_swiotlb() for userptr support
> (unless we add some approach for drivers to opt out of swiotlb).
swiotlb use is driven by three things:
1) addressing limitations of the device
2) addressing limitations of the interconnect
3) virtualiztion modes that require it
not sure how the driver could opt out. What is the problem with userptr
support?
> Then while I really want to get rid of GFP_DMA32 as well I'm not 100% sure
> if we can handle this without the flag.
Note that this is still using GFP_DMA32 underneath where required,
just in a layer that can decide that ѕensibly.
> And last we need something better to store the DMA address and order than
> allocating a separate memory object for each page.
Yeah. If you use __GFP_COMP for the allocations we can find the order
from the page itself, which might be useful. For 64-bit platforms
the dma address could be store in page->private, or depending on how
the page gets used the dma_addr field in struct page that overloads
the lru field and is used by the networking page pool could be used.
Maybe we could even have a common page pool between net and drm, but
I don't want to go there myself, not being an expert on either subsystem.
_______________________________________________
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
next prev parent reply other threads:[~2021-05-11 8:50 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-05-11 6:05 RFC: use dma_alloc_noncoherent in ttm_pool_alloc_page Christoph Hellwig
2021-05-11 6:05 ` [PATCH] drm/ttm: use dma_alloc_pages for the page pool Christoph Hellwig
2021-05-11 7:35 ` Christian König
2021-05-11 8:50 ` Christoph Hellwig [this message]
2021-05-11 8:57 ` Christian König
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=20210511085011.GA14477@lst.de \
--to=hch@lst.de \
--cc=airlied@linux.ie \
--cc=airlied@redhat.com \
--cc=alexander.deucher@amd.com \
--cc=amd-gfx@lists.freedesktop.org \
--cc=bskeggs@redhat.com \
--cc=christian.koenig@amd.com \
--cc=daniel@ffwll.ch \
--cc=dri-devel@lists.freedesktop.org \
--cc=iommu@lists.linux-foundation.org \
--cc=linux-graphics-maintainer@vmware.com \
--cc=maarten.lankhorst@linux.intel.com \
--cc=mripard@kernel.org \
--cc=nouveau@lists.freedesktop.org \
--cc=ray.huang@amd.com \
--cc=spice-devel@lists.freedesktop.org \
--cc=sroland@vmware.com \
--cc=tzimmermann@suse.de \
--cc=virtualization@lists.linux-foundation.org \
--cc=zackr@vmware.com \
/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