LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
From: "Christian König" <ckoenig.leichtzumerken@gmail.com>
To: Borislav Petkov <bp@alien8.de>, Alex Deucher <alexdeucher@gmail.com>
Cc: Tom Lendacky <thomas.lendacky@amd.com>,
	Paul Menzel <pmenzel@molgen.mpg.de>,
	Thomas Gleixner <tglx@linutronix.de>,
	Ingo Molnar <mingo@redhat.com>, X86 ML <x86@kernel.org>,
	Dave Hansen <dave.hansen@linux.intel.com>,
	Andy Lutomirski <luto@kernel.org>,
	Peter Zijlstra <peterz@infradead.org>,
	LKML <linux-kernel@vger.kernel.org>,
	amd-gfx list <amd-gfx@lists.freedesktop.org>
Subject: Re: `AMD_MEM_ENCRYPT_ACTIVE_BY_DEFAULT=y` causes AMDGPU to fail on Ryzen: amdgpu: SME is not compatible with RAVEN
Date: Thu, 7 Oct 2021 08:14:18 +0200	[thread overview]
Message-ID: <d3001b64-7b31-a0ab-d7d9-44b145d412f2@gmail.com> (raw)
In-Reply-To: <YV351s3Fyhnmen9g@zn.tnic>

Am 06.10.21 um 21:32 schrieb Borislav Petkov:
> On Wed, Oct 06, 2021 at 02:21:40PM -0400, Alex Deucher wrote:
>> And just another general comment, swiotlb + bounce buffers isn't
>> really useful on GPUs.  You may have 10-100s of MBs of memory mapped
>> long term into the GPU's address space for random access.  E.g., you
>> may have buffers in system memory that the display hardware is
>> actively scanning out of.  For GPUs you should really only enable SME
>> if IOMMU is enabled in remapping mode.  But that is probably beyond
>> the discussion here.
> Right, but insights into how these things work (or don't work) together
> are always welcome. And yes, as 2cc13bb4f59f says:
>
>      "... The bounce buffer
>      code has an upper limit of 256kb for the size of DMA
>      allocations, which is too small for certain devices and
>      causes them to fail."

To make the matter even worse, bounce buffers don't work with APIs like 
Vulkan and some OpenGL/OpenCL extensions.

In those APIs or extensions the assumption is that you can malloc() 
memory in userspace, give the pointer to the kernel driver and have 
coherent access with your device and the CPU at the same time.

In other words you don't even get the chance to bounce the buffers 
between CPU and device access because they are accessed by both at the 
same time.

Regards,
Christian.

  reply	other threads:[~2021-10-07  6:14 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-10-05 14:29 `AMD_MEM_ENCRYPT_ACTIVE_BY_DEFAULT=y` causes AMDGPU to fail on Ryzen: amdgpu: SME is not compatible with RAVEN Paul Menzel
2021-10-05 14:38 ` Borislav Petkov
2021-10-06  6:27   ` Paul Menzel
2021-10-05 14:48 ` Alex Deucher
2021-10-06  9:42   ` Borislav Petkov
2021-10-06 13:23     ` Alex Deucher
2021-10-06 13:46       ` Borislav Petkov
2021-10-06 14:01       ` Tom Lendacky
2021-10-06 17:48         ` Borislav Petkov
2021-10-06 18:10           ` Alex Deucher
2021-10-06 18:21             ` Alex Deucher
2021-10-06 19:32               ` Borislav Petkov
2021-10-07  6:14                 ` Christian König [this message]
2021-10-06 18:21             ` Borislav Petkov
2021-10-06 18:36               ` Alex Deucher
2021-10-06 19:34                 ` Borislav Petkov
2021-10-06 21:39                 ` Tom Lendacky
2021-10-11 13:05           ` Paul Menzel
2021-10-11 13:11             ` Borislav Petkov
2021-10-11 13:27               ` Tom Lendacky
2021-10-11 13:52                 ` Paul Menzel
2021-10-11 13:58                   ` Tom Lendacky
2021-10-11 14:21                     ` Paul Menzel
2021-10-11 14:28                       ` Tom Lendacky
2021-10-11 14:32                       ` Alex Deucher
2021-10-11 16:03                         ` [PATCH -v2] x86/Kconfig: Do not enable AMD_MEM_ENCRYPT_ACTIVE_BY_DEFAULT automatically Borislav Petkov
2021-10-11 16:05                           ` Alex Deucher
2021-10-11 16:29                           ` Tom Lendacky
2021-10-11 17:18 ` [tip: x86/urgent] " tip-bot2 for Borislav Petkov

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=d3001b64-7b31-a0ab-d7d9-44b145d412f2@gmail.com \
    --to=ckoenig.leichtzumerken@gmail.com \
    --cc=alexdeucher@gmail.com \
    --cc=amd-gfx@lists.freedesktop.org \
    --cc=bp@alien8.de \
    --cc=dave.hansen@linux.intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=luto@kernel.org \
    --cc=mingo@redhat.com \
    --cc=peterz@infradead.org \
    --cc=pmenzel@molgen.mpg.de \
    --cc=tglx@linutronix.de \
    --cc=thomas.lendacky@amd.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).