From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id B4F37C54EBD for ; Thu, 5 Jan 2023 22:09:02 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id D70E9900005; Thu, 5 Jan 2023 17:09:01 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id D21158E0001; Thu, 5 Jan 2023 17:09:01 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id BE96C900005; Thu, 5 Jan 2023 17:09:01 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0016.hostedemail.com [216.40.44.16]) by kanga.kvack.org (Postfix) with ESMTP id AF2938E0001 for ; Thu, 5 Jan 2023 17:09:01 -0500 (EST) Received: from smtpin08.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id 774ECA0626 for ; Thu, 5 Jan 2023 22:09:01 +0000 (UTC) X-FDA: 80322136482.08.69EC239 Received: from mail-oi1-f177.google.com (mail-oi1-f177.google.com [209.85.167.177]) by imf14.hostedemail.com (Postfix) with ESMTP id E60DA100004 for ; Thu, 5 Jan 2023 22:08:59 +0000 (UTC) Authentication-Results: imf14.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b=LPsmEqdA; spf=pass (imf14.hostedemail.com: domain of marcorr@google.com designates 209.85.167.177 as permitted sender) smtp.mailfrom=marcorr@google.com; dmarc=pass (policy=reject) header.from=google.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1672956539; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=bn7Z6oDABvJGYJVlfHzj/OFR2MilP9KE/xPylqtRaI8=; b=hX6V9uXIKQEFra9jfDEbEpbCUVZD+2Yg7P0GBkNe/PpMoK/XJ8wxkg6x4PNzgxsn2lB4iG 05qOIzNdmJb0NTYtyQoi6VgxbLM9r+iTmRo1/5Ji931zT+NGNf8pZJs8MFZYcJmaDYpo/j a75c56F2YCugRGT80JD90L9iwftCWBA= ARC-Authentication-Results: i=1; imf14.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b=LPsmEqdA; spf=pass (imf14.hostedemail.com: domain of marcorr@google.com designates 209.85.167.177 as permitted sender) smtp.mailfrom=marcorr@google.com; dmarc=pass (policy=reject) header.from=google.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1672956540; a=rsa-sha256; cv=none; b=bt80hH7zOfPOJGwveI8ogfWBrsJEGdIelb1puFd7IaWIjZE4Tr1wCHFH/DDc/Xcy+UqprQ yZsuYrcNU1RinDvQTiwL8hjXScP3XV6K8y0R2qbwKDr3j3bJyCrK3ivBiGMAe/dzNXttRt 8GNh75M0U2UvSooQV99ZKbz1HGokzMU= Received: by mail-oi1-f177.google.com with SMTP id h185so10650641oif.5 for ; Thu, 05 Jan 2023 14:08:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=bn7Z6oDABvJGYJVlfHzj/OFR2MilP9KE/xPylqtRaI8=; b=LPsmEqdAF17ASsCpSdQFeo9d4yZM+w20RGOPe9inlsD+sZCird0lne6ib9WTiUsoq6 2YgzaklAwt7/d/G7TwXebs7qINP7lo6g4gokBAoTDbEuLNRCPOur2bdGaSB5436CIeQq ow56Fuel0bIs5L34wyTU1If5GO/VcfHRlBWxOg8w8qsR3+7n9GR21BPqtWii9RShhyO4 sK4o0wllJQDfn0fBTBRKdj+90uTkehVGEmVCx2XkcMotlGcWsc49QFRAovOssriMnEgU 2rvFg916i1tZO2H3RWKP5p1gJ4gYmWV4zvrIbxxpj3BvvCGMhW7SujCWmA146HEcnYhg iNbg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=bn7Z6oDABvJGYJVlfHzj/OFR2MilP9KE/xPylqtRaI8=; b=H/lJ6Nj4W4qgSG4pwvUrIUrTdAy4KxRfI7RMPsUsHIkXn+E/syEgX5FX3r2io2aNxF ++bJ23XZ+ClG+Fz1VD1vYWRMZUQc0OR4xJ8pzratXlv799dvNB6/MFqwJGquHHCWVLXr w8oUO5WL8raQSwMxmJq/TI4BNfEBclz2ng+ZLWLYYQVyoCKQFYVNm7K4HDJ+7Hv0jcyn uPhIkG/O9ZdNtJmW1oTBHtWfMO/7mRy5X5IPtBpR4XH+JB7XJZYTE4WKKHz0ROTzWRVI NDSQO+cak4lPie2Ucc8u4JSrZtHgeF0HzqD5EBr0RfGg2nOaVboJeMZEgSc2WS4AY0EV v/gw== X-Gm-Message-State: AFqh2kpEudpLtpvGKIYYehm8YRJNiiIGZvzdkAEwYMq26b5MeQOza6gJ 0RM0Ln9UmTJv8YaN8YbnOnHoIETZ+x4BVo1/OZ+Aeg== X-Google-Smtp-Source: AMrXdXuxkMBtlIcBn4GdWW98m54t/OKdTbEuF+GncEMuoeBfYSSzt5Own7F/lydDPhj0/ruVF7sknqqThK7mIt4x8Js= X-Received: by 2002:a05:6808:3947:b0:354:7fd4:f17b with SMTP id en7-20020a056808394700b003547fd4f17bmr2403497oib.221.1672956538794; Thu, 05 Jan 2023 14:08:58 -0800 (PST) MIME-Version: 1.0 References: <243778c282cd55a554af9c11d2ecd3ff9ea6820f.1655761627.git.ashish.kalra@amd.com> <20221219150026.bltiyk72pmdc2ic3@amd.com> In-Reply-To: From: Marc Orr Date: Thu, 5 Jan 2023 14:08:47 -0800 Message-ID: Subject: Re: [PATCH Part2 v6 07/49] x86/sev: Invalid pages from direct map when adding it to RMP table To: "Kalra, Ashish" Cc: Borislav Petkov , Michael Roth , x86@kernel.org, linux-kernel@vger.kernel.org, kvm@vger.kernel.org, linux-coco@lists.linux.dev, linux-mm@kvack.org, linux-crypto@vger.kernel.org, tglx@linutronix.de, mingo@redhat.com, jroedel@suse.de, thomas.lendacky@amd.com, hpa@zytor.com, ardb@kernel.org, pbonzini@redhat.com, seanjc@google.com, vkuznets@redhat.com, jmattson@google.com, luto@kernel.org, dave.hansen@linux.intel.com, slp@redhat.com, pgonda@google.com, peterz@infradead.org, srinivas.pandruvada@linux.intel.com, rientjes@google.com, dovmurik@linux.ibm.com, tobin@ibm.com, vbabka@suse.cz, kirill@shutemov.name, ak@linux.intel.com, tony.luck@intel.com, sathyanarayanan.kuppuswamy@linux.intel.com, alpergun@google.com, dgilbert@redhat.com, jarkko@kernel.org Content-Type: text/plain; charset="UTF-8" X-Rspam-User: X-Rspamd-Server: rspam04 X-Rspamd-Queue-Id: E60DA100004 X-Stat-Signature: f8w1r33d1974szexjoymepzhpc4e6xtg X-HE-Tag: 1672956539-696898 X-HE-Meta: U2FsdGVkX18wpuzGv8tJmXuSJHMsLXeSjxr6QAFN9UmVEPxUEd4QXU83S+0rUNDGPCKUSAoVPb39FuyM0KkFtzpuACiknJsHKBcGLSbQ8irPM+hNh80ZAuJKNX6jyQjsX5RRIuyMwIc5lGGsTo2yAMYb94RKXb3llBS60gY2jIB5MjHGD2hsjkmAN/qxdf2FBc1jncHHYl75dxPUruQJiWPS6+HIwVKqrn7WrkLSfcVPtTL0W7yfQ6ACT83GZkkZpQjEyY02Eu0WRL5Wqt5FZjzLsNVlKbei+C8e9HoYg3j6wUHLzHXcb5AZPJ9IWUlU1L8wdIzU+o66OEKzpRwgNZvpocksPw9+bHgxE1Ae1zlXq6jkLVhizOrBJpXTy2a5nupV5ZHUwxUkjDs5V+p8OiMtVjNfkvHN0Fa9GcibVhf/3+we1gFMfJA3TAc66AHgmLYXcMElssC86QrziPugDtRHu39VtTJsMv2Z/Yd4LkGVZRuMUYMXeomm4fJnXV9Mv2hKCOVwEVDZEKRknSTYMg2Xeu2hVz9iJointKrwhK69qJonycwA8mIDsNzep0gHXS+jaQ9D9a+IzK6ZyD/I3k9UUS7n+BvY5d7928dos3QDU+moix169ekwAoZ/OQml1LQ7bKgym675GQ3MQmjOdYPhBaLm+owQ80paBTvH92jwYgxt7/kEYpT0nUafmeY8Uh41/dyNpwPEgY/6mqPzPvUGJPUgNPIFrok0h3n9UxdHfTN2VgUrpgYEpJT15CP0bPXbOkenoPWwRM9kfDvSQGhlQIkVmEkK0Eyo9feVcli2ICmQHnkESb2X2S3QZeb5kJox8s8/cBOA9OOOoieYu0vtTAyCtH3rijEtD5Dn7SN1/v01qpEQXlZx+8lUV6e6aKYZMnDeJwMFgLFJ63IR7jQnG0ja2kL6goE5uKB5QOzPyTnEq+Y3S1aAKHrBADmeYNelMgZ7oc7UrZCUTGF ojOvkpsk L871QQ1BQBcw37OY= X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Tue, Dec 27, 2022 at 1:49 PM Kalra, Ashish wrote: > > Hello Boris, > > On 12/19/2022 2:08 PM, Borislav Petkov wrote: > > On Mon, Dec 19, 2022 at 09:00:26AM -0600, Michael Roth wrote: > >> We implemented this approach for v7, but it causes a fairly significant > >> performance regression, particularly for the case for npages > 1 which > >> this change was meant to optimize. > >> > >> I still need to dig in a big but I'm guessing it's related to flushing > >> behavior. > > > > Well, AFAICT, change_page_attr_set_clr() flushes once at the end. > > > > Don't you need to flush when you modify the direct map? > > > > Milan onward, there is H/W support for coherency between mappings of the > same physical page with different encryption keys, so AFAIK, there > should be no need to flush during page state transitions, where we > invoke these direct map interface functions for re-mapping/invalidating > pages. > > I don't know if there is any other reason to flush after modifying > the direct map ? Isn't the Milan coherence feature (SME_COHERENT?) about the caches -- not the TLBs? And isn't the flushing being discussed here about the TLBs? Also, I thought that Mingwei Zhang found that the Milan SEV coherence feature was basically unusable in Linux because it only works across CPUs. It does not extend to IO (e.g., CPU caches need to be flushed prior to free'ing a SEV VM's private address and reallocating that location to a device driver to be used for IO). My understanding of this feature and its limitations may be too coarse. But I think we should be very careful about relying on this feature as it is implemented in Milan. That being said, I guess I could see an argument to rely on the feature here, since we're not deallocating the memory and reallocating it to a device. But again, I thought the feature was about cache coherence -- not TLB coherence.