From: "Luis R. Rodriguez" <mcgrof@kernel.org>
To: Dave Airlie <airlied@redhat.com>
Cc: torvalds@linux-foundation.org, dan.j.williams@intel.com,
x86@kernel.org, linux-kernel@vger.kernel.org,
dri-devel@lists.freedesktop.org, Toshi Kani <toshi.kani@hp.com>,
Borislav Petkov <bp@alien8.de>, "H. Peter Anvin" <hpa@zytor.com>,
Andy Lutomirski <luto@kernel.org>,
Denys Vlasenko <dvlasenk@redhat.com>,
Brian Gerst <brgerst@gmail.com>
Subject: Re: [PATCH 1/2] x86/io: add interface to reserve io memtype for a resource range. (v1.1)
Date: Tue, 25 Oct 2016 19:31:29 +0200 [thread overview]
Message-ID: <20161025173129.GD8651@wotan.suse.de> (raw)
In-Reply-To: <1477290706-7696-2-git-send-email-airlied@redhat.com>
On Mon, Oct 24, 2016 at 04:31:45PM +1000, Dave Airlie wrote:
> A recent change to the mm code in:
> 87744ab3832b83ba71b931f86f9cfdb000d07da5
> mm: fix cache mode tracking in vm_insert_mixed()
>
> started enforcing checking the memory type against the registered list for
> amixed pfn insertion mappings. It happens that the drm drivers for a number
> of gpus relied on this being broken. Currently the driver only inserted
> VRAM mappings into the tracking table when they came from the kernel,
> and userspace mappings never landed in the table. This led to a regression
> where all the mapping end up as UC instead of WC now.
Eek.
> I've considered a number of solutions but since this needs to be fixed
> in fixes and not next, and some of the solutions were going to introduce
> overhead that hadn't been there before I didn't consider them viable at
> this stage. These mainly concerned hooking into the TTM io reserve APIs,
> but these API have a bunch of fast paths I didn't want to unwind to add
> this to.
>
> The solution I've decided on is to add a new API like the arch_phys_wc
> APIs (these would have worked but wc_del didn't take a range), and
> use them from the drivers to add a WC compatible mapping to the table
> for all VRAM on those GPUs. This means we can then create userspace
> mapping that won't get degraded to UC.
Is anything on a driver to be able to tell when this is actually needed ?
How will driver developers know? Can you add a bit of documentation to
the API? If its transitive towards a secondary solution indicating so
would help driver developers.
Luis
next prev parent reply other threads:[~2016-10-25 17:31 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-10-24 6:31 x86 PAT memtype regression fixes (with extra cc's) Dave Airlie
2016-10-24 6:31 ` [PATCH 1/2] x86/io: add interface to reserve io memtype for a resource range. (v1.1) Dave Airlie
2016-10-25 9:40 ` Ingo Molnar
2016-10-25 11:10 ` Thomas Gleixner
2016-10-25 17:31 ` Luis R. Rodriguez [this message]
2016-10-26 5:49 ` Daniel Vetter
2016-10-26 6:12 ` Dave Airlie
2016-10-26 7:00 ` Daniel Vetter
2016-10-26 7:00 ` Daniel Vetter
2016-10-26 17:48 ` [PATCH] x86/pat, mm: Make track_pfn_insert() return void Borislav Petkov
2016-10-26 17:48 ` Borislav Petkov
2016-11-09 20:42 ` [tip:mm/pat] " tip-bot for Borislav Petkov
2016-10-24 6:31 ` [PATCH 2/2] drm/drivers: add support for using the arch wc mapping API Dave Airlie
2016-10-24 6:31 ` Dave Airlie
2016-10-24 9:24 ` Christian König
-- strict thread matches above, loose matches on Subject: below --
2016-10-24 6:28 x86 PAT memtype regression fixes Dave Airlie
2016-10-24 6:28 ` [PATCH 1/2] x86/io: add interface to reserve io memtype for a resource range. (v1.1) Dave Airlie
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=20161025173129.GD8651@wotan.suse.de \
--to=mcgrof@kernel.org \
--cc=airlied@redhat.com \
--cc=bp@alien8.de \
--cc=brgerst@gmail.com \
--cc=dan.j.williams@intel.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=dvlasenk@redhat.com \
--cc=hpa@zytor.com \
--cc=linux-kernel@vger.kernel.org \
--cc=luto@kernel.org \
--cc=torvalds@linux-foundation.org \
--cc=toshi.kani@hp.com \
--cc=x86@kernel.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.