LKML Archive on lore.kernel.org help / color / mirror / Atom feed
From: Tom Lendacky <email@example.com> To: Alex Deucher <firstname.lastname@example.org>, Borislav Petkov <email@example.com> Cc: Paul Menzel <firstname.lastname@example.org>, Thomas Gleixner <email@example.com>, Ingo Molnar <firstname.lastname@example.org>, X86 ML <email@example.com>, Dave Hansen <firstname.lastname@example.org>, Andy Lutomirski <email@example.com>, Peter Zijlstra <firstname.lastname@example.org>, LKML <email@example.com>, amd-gfx list <firstname.lastname@example.org> Subject: Re: `AMD_MEM_ENCRYPT_ACTIVE_BY_DEFAULT=y` causes AMDGPU to fail on Ryzen: amdgpu: SME is not compatible with RAVEN Date: Wed, 6 Oct 2021 09:01:56 -0500 [thread overview] Message-ID: <email@example.com> (raw) In-Reply-To: <CADnq5_N5+SEW4JyXLc=FdSHnSbXrGKWjEw4vW1Jxv9-KdWf+Jg@mail.gmail.com> On 10/6/21 8:23 AM, Alex Deucher wrote: > On Wed, Oct 6, 2021 at 5:42 AM Borislav Petkov <firstname.lastname@example.org> wrote: >> >> On Tue, Oct 05, 2021 at 10:48:15AM -0400, Alex Deucher wrote: >>> It's not incompatible per se, but SEM requires the IOMMU be enabled >>> because the C bit used for encryption is beyond the dma_mask of most >>> devices. If the C bit is not set, the en/decryption for DMA doesn't >>> occur. So you need IOMMU to be enabled in remapping mode to use SME >>> with most devices. Raven has further requirements in that it requires >>> IOMMUv2 functionality to support some features which currently uses a >>> direct mapping in the IOMMU and hence the C bit is not properly >>> handled. >> >> So lemme ask you this: do Raven-containing systems exist out there which >> don't have IOMMUv2 functionality and which can cause boot failures when >> SME is enabled in the kernel .config? > > There could be some OEM systems that disable the IOMMU on the platform > and don't provide a switch in the bios to enable it. The GPU driver > will still work in that case, it will just not be able to enable KFD > support for ROCm compute. SME won't work for most devices in that > case however since most devices have a DMA mask too small to handle > the C bit for encryption. SME should be dependent on IOMMU being > enabled. That's not completely true. If the IOMMU is not enabled (off or in passthrough mode), then the DMA api will check the DMA mask and use SWIOTLB to bounce the DMA if the device doesn't support DMA at the position where the c-bit is located (see force_dma_unencrypted() in arch/x86/mm/mem_encrypt.c). To avoid bounce buffering, though, commit 2cc13bb4f59f was introduced to disable passthrough mode when SME is active (unless iommu=pt was explicitly specified). Thanks, Tom > >> >> IOW, can we handle this at boot time properly, i.e., disable SME if we >> detect Raven or IOMMUv2 support is missing? >> >> If not, then we really will have to change the default. > > I'm not an SME expert, but I thought that that was already the case. > We just added the error condition in the GPU driver to prevent the > driver from loading when the user forced SME on. IIRC, there were > users that cared more about SME than graphics support. > > Alex > >> >> Thx. >> >> -- >> Regards/Gruss, >> Boris. >> >> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpeople.kernel.org%2Ftglx%2Fnotes-about-netiquette&data=04%7C01%7Cthomas.lendacky%40amd.com%7Cbab2eedbc1704f90f63408d988cc7fb2%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637691234178637291%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=xCXc1pcfJiWvKG1DTJKq986Ecid8M7M7K3gvCDWrZL8%3D&reserved=0
next prev parent reply other threads:[~2021-10-06 14:02 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 [this message] 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 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 \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.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: linkBe 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).