linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Ingo Molnar <mingo@kernel.org>
To: Dave Airlie <airlied@redhat.com>
Cc: mcgrof@suse.com, 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 11:40:07 +0200	[thread overview]
Message-ID: <20161025094007.GA15819@gmail.com> (raw)
In-Reply-To: <1477290706-7696-2-git-send-email-airlied@redhat.com>


* Dave Airlie <airlied@redhat.com> 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.
> 
> 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.
> 
> v1.1: use CONFIG_X86_PAT
> Cc: Toshi Kani <toshi.kani@hp.com>
> Cc: Borislav Petkov <bp@alien8.de>
> Cc: H. Peter Anvin <hpa@zytor.com>
> Cc: Andy Lutomirski <luto@kernel.org>
> Cc: Denys Vlasenko <dvlasenk@redhat.com>
> Cc: Brian Gerst <brgerst@gmail.com>
> Cc: x86@kernel.org
> Cc: mcgrof@suse.com
> Cc: Dan Williams <dan.j.williams@intel.com>
> Signed-off-by: Dave Airlie <airlied@redhat.com>
> ---
>  arch/x86/include/asm/io.h |  6 ++++++
>  arch/x86/mm/pat.c         | 13 +++++++++++++
>  include/linux/io.h        | 13 +++++++++++++
>  3 files changed, 32 insertions(+)

These changes look good to me in principle:

  Acked-by: Ingo Molnar <mingo@kernel.org>

I think it would be best to merge these fixes via the DRM tree?

Thanks,

	Ingo

  reply	other threads:[~2016-10-25  9:40 UTC|newest]

Thread overview: 13+ 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 [this message]
2016-10-25 11:10   ` Thomas Gleixner
2016-10-25 17:31   ` Luis R. Rodriguez
2016-10-26  5:49     ` Daniel Vetter
2016-10-26  6:12       ` Dave Airlie
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-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  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=20161025094007.GA15819@gmail.com \
    --to=mingo@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=mcgrof@suse.com \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).