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 F2E61C3DA7A for ; Thu, 5 Jan 2023 22:32:01 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 6CFE68E0002; Thu, 5 Jan 2023 17:32:01 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 6A66B8E0001; Thu, 5 Jan 2023 17:32:01 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 595768E0002; Thu, 5 Jan 2023 17:32:01 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0012.hostedemail.com [216.40.44.12]) by kanga.kvack.org (Postfix) with ESMTP id 49CE78E0001 for ; Thu, 5 Jan 2023 17:32:01 -0500 (EST) Received: from smtpin20.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id 18DDA1402C5 for ; Thu, 5 Jan 2023 22:32:01 +0000 (UTC) X-FDA: 80322194442.20.78F789A Received: from mail-oa1-f41.google.com (mail-oa1-f41.google.com [209.85.160.41]) by imf26.hostedemail.com (Postfix) with ESMTP id 77E45140003 for ; Thu, 5 Jan 2023 22:31:59 +0000 (UTC) Authentication-Results: imf26.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b=irhVthMk; spf=pass (imf26.hostedemail.com: domain of marcorr@google.com designates 209.85.160.41 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=1672957919; 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=bzW/w/1hM8B3dAJhNRkp0Jphokn3JFk7Z5V07SJ3Qvg=; b=qi1j7ZWioXt4qE08jZcVqJGMisMLDGZ5Xw9an1aIVcFJez4W2CN4wulI0JqYweiAEdhwBY yzQApVOZ8EI+Z3/9Y8f/7Io4Ge67TjfDkuwsZaBm4ZebCgJqdsJhqm1HsQTiOS00hobfR8 N5BYxO68jE7ki8flbDo7WpN58OY4dJQ= ARC-Authentication-Results: i=1; imf26.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b=irhVthMk; spf=pass (imf26.hostedemail.com: domain of marcorr@google.com designates 209.85.160.41 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=1672957919; a=rsa-sha256; cv=none; b=adLN/b3bWRHASsPTLs7O5U5fw/UL0Bia/aggzMfj9qB2ZRkGEnZA4yLlOiapXIaihRkgNQ ETpmcjjs+5uXSlXYmgKpPa5Nb78kmDWRfbjJl39CV9JYMOCB6DlDF6tGkKqX84BdtBAekc Pjlpe7rEsbav7dJRrNF+S6e40zT/ygA= Received: by mail-oa1-f41.google.com with SMTP id 586e51a60fabf-15027746720so29477928fac.13 for ; Thu, 05 Jan 2023 14:31: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=bzW/w/1hM8B3dAJhNRkp0Jphokn3JFk7Z5V07SJ3Qvg=; b=irhVthMkbXMEX15iArMrcDY5gNuF5eBvK4eo1OtUylhsmE3IG9S+mrhZxQOiqFOCIp B0NdfYGQgplol+qXFg23OWfulPwvSU6W3PDU1vto6PpvE0VAeFfNIFN4a8ZuHbQY9yux PXeSKyeq3An9rFPoa3fVNGzGEqqWpmTNW/IhDMPZHTEGo5GXlC3tHCL+PpUMhytJ91mi VnE7MFoMeikcgMvkL5CbthLdijfrodW+nJq5InxHQqUSFW5SY7wrPzcsnCf8IgP9ADVl OSDDZsGxvXwBgux7z61kSSUwbOnmCiTQmx5XrBl1LtTxgEFPc4Tdi1LcRhBuf47g7+EW 8CKA== 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=bzW/w/1hM8B3dAJhNRkp0Jphokn3JFk7Z5V07SJ3Qvg=; b=1Ub+kwgjF4WBZvEZ/yO52Fwe0UZvHWA42qhh4oRPFfDn3EKcKjrryrc0OKVS7zmT+b HQaS2x6dGlFfpOKCC7kjMQILEM8F/V7f4wzLVExm8UnUmUX0F3v7kCMf1oWsbAPwYIRR pqMdPEikUW3Wp14YKrvoidDfMbUiJaU7op0BmZ0JIioP6lvcBljjhgDmfiu78cujC7VM 3hFCzZs5z0iNm8jFs+xvqvWEuqdLAfrzPplX1Wv2jE8hE5EPGW6SbTEZx4G9s+E7LYhP JLlPz1rheon6mfPG9rUfMuzxNnUpMf0O4hY3LVCyILLPt9aGJpBNyC/e4LI0aErqxcvS 49Ag== X-Gm-Message-State: AFqh2kpM8sDBrB58TqvNzzthGIAzba4xEXmpVCTdjYmrBfeEbR2akp4x gV2AR7AdQBV/TJz79vJK6jkYfnFTpp5c8gWBUL1nUw== X-Google-Smtp-Source: AMrXdXuhK0FyKkeqVW5l22eKW+0UG+HL1l0rnz8gKZ4dAVgXGahu6I04Z2YvHkfHXjMPojl5mAzlig7pu90phEAYxnc= X-Received: by 2002:a05:6870:b020:b0:14f:9d87:3d58 with SMTP id y32-20020a056870b02000b0014f9d873d58mr4259851oae.108.1672957918361; Thu, 05 Jan 2023 14:31:58 -0800 (PST) MIME-Version: 1.0 References: <243778c282cd55a554af9c11d2ecd3ff9ea6820f.1655761627.git.ashish.kalra@amd.com> <20221219150026.bltiyk72pmdc2ic3@amd.com> <993e0896-cda6-5033-ad0e-e21508a58077@amd.com> In-Reply-To: <993e0896-cda6-5033-ad0e-e21508a58077@amd.com> From: Marc Orr Date: Thu, 5 Jan 2023 14:31: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: 77E45140003 X-Stat-Signature: dhxgbqd167yxm84b4bwa9pj3dmmfzuki X-HE-Tag: 1672957919-640355 X-HE-Meta: U2FsdGVkX18KqlY3YWPyo8A6VXzRsvsruikDtydiVnWeoL5jFLgzXEVKaTOnLLTwPgvRQhIX1PFjbteLn+f2tZOnj2lOUUU9G7BFL8cjAchtt59Zvz2pWNExs9eqpCTdIJyYlRT+05hCt5Dl5mX9cX2qG5D/jM0JlZii9k3viVdRsaK+qorqQwH4a+x0z73PHD3svffhRl32c8CtfPp0xL1w8cY6dz3aZ2e8Bz0Z8/plvx4Arbp233QO60LZCJbyvYVjGXDhfQFNy3W25DC2Zuicbj24370ktDpqxnOc/8ieHwOyGA50MCN4MxhCOWHPQ3WZn4U5u8no08e/9jWmC1X9eaMjB5G5tMLF7czwLvaHl4YOLWFLGmWVaaiNzqvMs/Qa1wbJdw3LTkm+F5G2dBE5K+e5Mkc6Jz43+OCsOyBNFKbXnTOHNr2PxkRNZDfIx+WJaXmEKHwoI2eygi2QDG3bSLfEfu6C6URJkXYwSqS7f1GMJ7yNwD/33E8wB+OeFNNO0GHRkUF2XyLKytRCTdPpMvjo8qtz3r09/82W68XVWkrxxc1r2WVMCIuRWay9OTpfk2Ag8Z0m4fi0a4vh5PiNxmBSUrS++8oI5p4jSnIYGLylxyASGafY+/FVohJf34q59aCwyI8n+uAgkPKbs11dlb7AAztcQS2jAu63GsgpD6Q3OQE2wweFdy/OQwcOKhre7tAEwVj5MlidYk68l5qvLNUSeihyoOH9Q7IneRz/rnGApu05G0lfHm7RjLhtlNKyUPLQgkvQInOOS1yUipPheCemIUYFdoTFCXK6ZoKG73EuErcMyn0mWXvDYZ/eg8Eyh87jmfdSJDulivxv9g5WV4YFO3NZVrYC5BKz+PcOeICeSe03r+O7GulxpAM+c/BlyWhOuDmmldSaGVXvooNNK0h8IWONR3EAZhJGBDEGC8/bieGE6dEpL7TW9wx+9S15nrNh37PboAcKIoG s7cw3Rai 3MxjALcIo1ET+YQw= 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 Thu, Jan 5, 2023 at 2:27 PM Kalra, Ashish wrote: > > Hello Marc, > > On 1/5/2023 4:08 PM, Marc Orr wrote: > > 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? > > Actually, the flush does both cache and TLB flushing. > > Both cpa_flush() and cpa_flush_all() will also do cache flushing if > cache argument is not NULL. As in this case, no page caching attributes > are being changed so there is no need to do cache flushing. > > But TLB flushing (as PTE is updated) is still required and will be done. Ah, got it now. Thanks for explaining. (I should've looked at the code a bit closer.) > > 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. > > Yes, this is just invalidating or re-mapping into the kernel direct map, > so we can rely on this feature for the use case here. SGTM and that does make sense then. Thanks for confirming.