Received: by 2002:a05:6a10:d5a5:0:0:0:0 with SMTP id gn37csp1062885pxb; Wed, 6 Oct 2021 23:17:08 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwC+57TR7gxxSBWd3rfdR4BEZ4d1XL88H3lOR0Y1eBYo55euvEAadGS0iHNrmWntKQ4P4TS X-Received: by 2002:aa7:dbca:: with SMTP id v10mr3687182edt.280.1633587427966; Wed, 06 Oct 2021 23:17:07 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1633587427; cv=none; d=google.com; s=arc-20160816; b=lGanjHZ1UP8yTbzABZJLD41E7mTUEN3ykLmm0UoROKcJ2Cok380Jco7sZaWCfoIrC1 U2bgR7we089TVJd8+5++LQrpXJIq8k2wxhqjLdp8wKreP7agnb0TC1eH4rCxKpteElqi cYP8phrkBEZzM4bS6k8RfzM/ru39s5YI6hGKgJs/zcYEZ8XTAy5fdmLBih97DWhKyCG4 mMJVyxwNfj96o1prR50bsLBDe8WwhnRJJJVR5/v5eKF9COAooKg3V40GXd3INiXyELzT VHCY4loK6YIWaejZOE7ezzaFi9YoqM86KNHsYMf1TTW7DbWM7kofNDHThCdX2oqEBkzL 9BbQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-language:content-transfer-encoding :in-reply-to:mime-version:user-agent:date:message-id:from:references :cc:to:subject:dkim-signature; bh=gI5co4o1rYvGRdi2WZK3gX+GZfZ3PfZ5qkVmEV61ypM=; b=y32NTe1cIiIki59t+ZOhjq4vHtHd2n2B8XjAXO26rFX2u1Uo4ZNqEUgRH50bmYTvrz AdmQnhDB7GOvFxTNZcBOmtRs3DgxrrFXn4PoE4zdN1Sv1u+BLTcf/Tb2Ebbd6D9sqrY7 Z13plKfurGN4AHL/54QSJEAR49INCeZ+LLJIFCD4u/FQwwoC3R1VrkmyuoJqqVZLSP7d Sb3ndIf+Ca333UulR25WA5Yt8kVcSZayYeNpMy9R1nDdHEgoaHbWfvbk+e6XQc1LhLnO HbI0QFZOoYYC4dzcF790jNite6jKpoUqIb8UWRsFmXpt9jm+i0RKurB6KEZo1zyxxI7B kGcg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20210112 header.b=ipDEUW6f; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id k3si27860859edx.240.2021.10.06.23.16.44; Wed, 06 Oct 2021 23:17:07 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com header.s=20210112 header.b=ipDEUW6f; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S240221AbhJGGQV (ORCPT + 99 others); Thu, 7 Oct 2021 02:16:21 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:54864 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232427AbhJGGQQ (ORCPT ); Thu, 7 Oct 2021 02:16:16 -0400 Received: from mail-wr1-x42e.google.com (mail-wr1-x42e.google.com [IPv6:2a00:1450:4864:20::42e]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 9866BC061746 for ; Wed, 6 Oct 2021 23:14:22 -0700 (PDT) Received: by mail-wr1-x42e.google.com with SMTP id t8so15594723wri.1 for ; Wed, 06 Oct 2021 23:14:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding:content-language; bh=gI5co4o1rYvGRdi2WZK3gX+GZfZ3PfZ5qkVmEV61ypM=; b=ipDEUW6fCIZj20IJZstMPYxQ5mXG1IB8w198w1WbBiD70rzgEr3CURVfEnGenTJJ8C uxmcxXru1MZ4v2vA5sc6AgUZRHqHm2goP6/NKjqRuQmypVn9DTxrGiWDfdZ0qksjIQVe afgs+fOmqP5uKYzoxOyE7U7eur5LObBtvcca7cK1q03L0t3hO44ACd8OofMwpt8dmHOv hrj+2yQ79BZ9sD01FXkhgTE8sMBMMWiaGmLd2NfK1zK/GmJDOQzoFexdrN/kCigCb4sz otor5Gy84gq1s9Ck2WUKEyaMqG6DMuRONHolPyCmYL0Y+9Lv03sndKZze5kYNPLV194D S5ug== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=gI5co4o1rYvGRdi2WZK3gX+GZfZ3PfZ5qkVmEV61ypM=; b=a9wdaVPExRkCkwlBbfBeuKKhVYKZsqGaNDw+QcDJB3BuPwbSbhwqumO4mLFINrFV6Y bKEasKkjj/IWx2evyYKD7CMz6PIRyT9RGXI89VeReIUuRjIvIzgbdtSo75g3w+7pGEPo Lsfdulx8bo9MR/odZxdtERK1GQWFsFqIYefN0+MNnDb/rVUobGagrmQjHk9Vd25NmtuB jWuXf1d0DbbMoDlzMzi6XqasEOvBoNjcA88p6RHvZcjVjlDjBnRb6CjmbP5MxqG/9Vuo QIMOXwQfJz0sTdmU2+hKZ6jZrLHsX89MoHwDVLsdGGVDlmAtqOwZGRniz/Bmc0/msMgn bFXA== X-Gm-Message-State: AOAM532EuZYoVMoOydbw3NZqw79Ld4HTGsEJFGObQu/cGO2RnJvU9xk0 XxnmyQ3aU/R+nTHyw5sm0Eo= X-Received: by 2002:adf:8b15:: with SMTP id n21mr3033384wra.373.1633587260830; Wed, 06 Oct 2021 23:14:20 -0700 (PDT) Received: from [192.168.178.21] (p5b0ea1b5.dip0.t-ipconnect.de. [91.14.161.181]) by smtp.gmail.com with ESMTPSA id a25sm7147675wmj.34.2021.10.06.23.14.19 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 06 Oct 2021 23:14:20 -0700 (PDT) Subject: Re: `AMD_MEM_ENCRYPT_ACTIVE_BY_DEFAULT=y` causes AMDGPU to fail on Ryzen: amdgpu: SME is not compatible with RAVEN To: Borislav Petkov , Alex Deucher Cc: Tom Lendacky , Paul Menzel , Thomas Gleixner , Ingo Molnar , X86 ML , Dave Hansen , Andy Lutomirski , Peter Zijlstra , LKML , amd-gfx list References: <8bbacd0e-4580-3194-19d2-a0ecad7df09c@molgen.mpg.de> <96f6dbed-b027-c65e-6888-c0e8630cc006@amd.com> From: =?UTF-8?Q?Christian_K=c3=b6nig?= Message-ID: Date: Thu, 7 Oct 2021 08:14:18 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.13.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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.