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 A8889C4706C for ; Fri, 12 Jan 2024 14:50:26 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 37E7C6B008A; Fri, 12 Jan 2024 09:50:26 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 32E716B008C; Fri, 12 Jan 2024 09:50:26 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 1F6036B0092; Fri, 12 Jan 2024 09:50:26 -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 110D96B008A for ; Fri, 12 Jan 2024 09:50:26 -0500 (EST) Received: from smtpin19.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id D6966160DB7 for ; Fri, 12 Jan 2024 14:50:25 +0000 (UTC) X-FDA: 81670944810.19.2645796 Received: from mail.alien8.de (mail.alien8.de [65.109.113.108]) by imf01.hostedemail.com (Postfix) with ESMTP id 6C61940010 for ; Fri, 12 Jan 2024 14:50:23 +0000 (UTC) Authentication-Results: imf01.hostedemail.com; dkim=pass header.d=alien8.de header.s=alien8 header.b="Uq/rcauV"; spf=pass (imf01.hostedemail.com: domain of bp@alien8.de designates 65.109.113.108 as permitted sender) smtp.mailfrom=bp@alien8.de; dmarc=pass (policy=none) header.from=alien8.de ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1705071024; a=rsa-sha256; cv=none; b=8AT6d3bXVEPvJs+QnIi7vU42TeeHryauFUwLTqAGjP6n4kz+z7YxB3Vy0ricx5to4a4S7S lnc2fd9MvrOTM0CWz+D/cRxPHUA6p4do6mAfAGpaTJECEHcMuocP+cmxXOEoVnpnlhMX0B gv8+8Ma4UxTAR8I4APuMKh3YFL6VGt4= ARC-Authentication-Results: i=1; imf01.hostedemail.com; dkim=pass header.d=alien8.de header.s=alien8 header.b="Uq/rcauV"; spf=pass (imf01.hostedemail.com: domain of bp@alien8.de designates 65.109.113.108 as permitted sender) smtp.mailfrom=bp@alien8.de; dmarc=pass (policy=none) header.from=alien8.de ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1705071024; 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=nqVhozkdasMvoNMNWSSH6FJXsbVj0/v6l5vQpljdmiQ=; b=sV0kjuQuCArSAvMDoyccQlf5pxyO8qZIB+FVMS02aQJFQZdDW7DZe8EpX3IiVxn8ypkmKd Xe/4P69qcxrltl8WsXend9Flx4yAceEeLtAbv/iKHFZeHxqjNRG9DHAAXH44v+IoBrmT0f 0/OjJNXFJdBN0Tg5oCaogyLgutzHnOc= Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.alien8.de (SuperMail on ZX Spectrum 128k) with ESMTP id 2195A40E01BB; Fri, 12 Jan 2024 14:50:19 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at mail.alien8.de Received: from mail.alien8.de ([127.0.0.1]) by localhost (mail.alien8.de [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id j0ZiORjLOv0g; Fri, 12 Jan 2024 14:50:17 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alien8.de; s=alien8; t=1705071016; bh=nqVhozkdasMvoNMNWSSH6FJXsbVj0/v6l5vQpljdmiQ=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=Uq/rcauVAF/rPaiz6zG4iwcyP/DJrKvon5cm7DsCpvv4EfqvJbpDlNpRuNhfhu72L n8IrDjE75/gjytSFQmBDYV+RfXzJ5yPbmWYErAT4jGQHPgp9fTYohyoE/hw6Ic509I EoKI50jTnVkmhyJb73dkILrUIECLcmIj8qFIsZS0LSzioXwtpKYMdTyVeCzOp+jTAu eswxAZ6hDFO/fdZBLGyMWGSbn+hdpFC72aRyo2dLJaHPSGHiWrawt6r1nl/QpSOZEq po0eksPZQ3C5njl94LFXpntvJxTOSx/1TpV4ZHecnzsEvRgDodYPzfu7vznZi1knt5 e11dAhUw4NtAGRdUsBK5wIs9HFPwAc/bayH04wPymSCxGKgNBMX68hI2nTmcfQxdZR jDqwIBJKuiBIEEETVzTvKfLT0bN3FMAiRnQzvHxvGalGKUbxX7bh+8lg5Whx5MSOC1 W+/5lMfe87IhbXpJFI+X4WIUjnVT2dUA4imi3IR/AKWcErPvsHeAgxmv5vgUdlf9bm FZyjY+aOH8hxRoWUWFCEsBQ2BGhEHTxa4HjzR8ymv8uO60uwA/S85/BgcTGfBenv1Y 48POGnd7/NvuF/kg3fM8WUIzdT/x9J+Hj9IhZc2TjQezZuldVKsalPi3428QxA45E0 sVyGs7NksRVilK6HjRwuPKo4= Received: from zn.tnic (pd9530f8c.dip0.t-ipconnect.de [217.83.15.140]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature ECDSA (P-256) server-digest SHA256) (No client certificate requested) by mail.alien8.de (SuperMail on ZX Spectrum 128k) with ESMTPSA id 441A340E016C; Fri, 12 Jan 2024 14:49:38 +0000 (UTC) Date: Fri, 12 Jan 2024 15:49:31 +0100 From: Borislav Petkov To: Michael Roth Cc: x86@kernel.org, kvm@vger.kernel.org, linux-coco@lists.linux.dev, linux-mm@kvack.org, linux-crypto@vger.kernel.org, linux-kernel@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, 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, jarkko@kernel.org, ashish.kalra@amd.com, nikunj.dadhania@amd.com, pankaj.gupta@amd.com, liam.merwick@oracle.com, zhi.a.wang@intel.com, Brijesh Singh Subject: Re: [PATCH v1 10/26] x86/sev: Add helper functions for RMPUPDATE and PSMASH instruction Message-ID: <20240112144931.GCZaFRewg1ft-oS_rY@fat_crate.local> References: <20231230161954.569267-1-michael.roth@amd.com> <20231230161954.569267-11-michael.roth@amd.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20231230161954.569267-11-michael.roth@amd.com> X-Rspamd-Server: rspam08 X-Rspamd-Queue-Id: 6C61940010 X-Stat-Signature: ws33iw1j55q4c467req46mfadx4fi7uq X-Rspam-User: X-HE-Tag: 1705071023-114493 X-HE-Meta: U2FsdGVkX1+EKJ0igtQpv92nHNaoX5di6H9PUCtwTpBY4yd0dwFAmmMg3f91OEZify3pb3/oIFaeqOCTkjX8MmU0os9L4UHvuJyEvJKrrwFL45tiQBKCojOimiGwgMKz9VvW1zkUKtegJFmJoyvlUu4Fh0keqHIaW3jNaMp5QEbv+Hhj8GjD7AAStJyUXzNWLOAtrX7bZfpUvEoetjRoTH2eFJHrS8qsRJCSqGUiqR5yuo/DWskgl3t0lJ4S5rwyl9W0rE1C2MGS21PuKrbjWG5Wtrqc/o34mETjPO/iPZm9Yzm3cgsmhPGhio89sCzu2lxWcLW0MtDHxeahgr/dTi45xALc4a17IR4T2zKwTmkyEDA7zAHxrStJYee2sony+jEM27NaxH7Q5QT1U83Ut+w3pdQ4svMYg4UjKIkodK+REwXSAyzybTOlA7k56wuNu1nG+2vqchTBXF9c3yA2KalDht610ydKH/IsifgFiatXhpuBe8j9SBjHpM4YhMLWlMNAHgGmbr6FKGTAPiyhvZaGUJvdEMekaEROCVuAORyHgPj+NM0IDsCw7UbPnYhzEtGDqxhEye8rcKidZVJeY+GlBUNnUqhL/hc/C1dJ9zCbAxZ56h5PnRw9HmzotIOZULsvu+YqHn7QOVrZfsXhWNOirNFQo7rE7K9a1c8xOg51ygktXFnQjoFP2GDT4jLLX+GieQANX1sFrLBmchg/4dKLfCOsGytvd4ogkjUY33PPMtOQTc41IxboE3zdBqIj4OUkPPp3tKHcIWAWYcdndTc7LkJZsbQbaAG3T6dXGZQCu7UF0oP4MzfOCsLvZWYWyw5va74Yyt7x2xwbs33Q2uxtGu4YFbzBHQuhHjish+rN22CsZYO3lvPbKGBuizJ+SlDde5+U6Vg1Ke6y9qeG2h5iwF81v/zolKuwnFZi1PI90Is12WSy4nT7+xMyzRyJdqy4raOKhh0H4ATl72e BKHAu4bm xJrNalMhTP63F5TvgG8CXHfK2Yax55r3mk4M01Wyy3ubG4gBglKoSJ5uRGljQlsUpW4ikhb5XEqAv5E6/voL7OUDOYXlG1qW7ruizq4OVkhJLzHeMsrhD8EwHPnhyzd4zWigpxtSVuekowoaCe6FyKY9LJYhRP9mQsUL6Mz2pC2puMudzMmFmy/C49kQTxq1FJtWfkzq2CHQpzpI= 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: List-Subscribe: List-Unsubscribe: On Sat, Dec 30, 2023 at 10:19:38AM -0600, Michael Roth wrote: > +static int rmpupdate(u64 pfn, struct rmp_state *state) > +{ > + unsigned long paddr = pfn << PAGE_SHIFT; > + int ret; > + > + if (!cpu_feature_enabled(X86_FEATURE_SEV_SNP)) > + return -ENODEV; > + Let's document this deal here and leave the door open for potential future improvements: --- diff --git a/arch/x86/virt/svm/sev.c b/arch/x86/virt/svm/sev.c index c9156ce47c77..1fbf9843c163 100644 --- a/arch/x86/virt/svm/sev.c +++ b/arch/x86/virt/svm/sev.c @@ -374,6 +374,21 @@ static int rmpupdate(u64 pfn, struct rmp_state *state) if (!cpu_feature_enabled(X86_FEATURE_SEV_SNP)) return -ENODEV; + /* + * It is expected that those operations are seldom enough so + * that no mutual exclusion of updaters is needed and thus the + * overlap error condition below should happen very seldomly and + * would get resolved relatively quickly by the firmware. + * + * If not, one could consider introducing a mutex or so here to + * sync concurrent RMP updates and thus diminish the amount of + * cases where firmware needs to lock 2M ranges to protect + * against concurrent updates. + * + * The optimal solution would be range locking to avoid locking + * disjoint regions unnecessarily but there's no support for + * that yet. + */ do { /* Binutils version 2.36 supports the RMPUPDATE mnemonic. */ asm volatile(".byte 0xF2, 0x0F, 0x01, 0xFE" > + do { > + /* Binutils version 2.36 supports the RMPUPDATE mnemonic. */ > + asm volatile(".byte 0xF2, 0x0F, 0x01, 0xFE" > + : "=a" (ret) > + : "a" (paddr), "c" ((unsigned long)state) > + : "memory", "cc"); > + } while (ret == RMPUPDATE_FAIL_OVERLAP); > + > + if (ret) { > + pr_err("RMPUPDATE failed for PFN %llx, ret: %d\n", pfn, ret); > + dump_rmpentry(pfn); > + dump_stack(); > + return -EFAULT; > + } > + > + return 0; > +} -- Regards/Gruss, Boris. https://people.kernel.org/tglx/notes-about-netiquette