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 15E08C35274 for ; Mon, 18 Dec 2023 14:58:48 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 995B28D0008; Mon, 18 Dec 2023 09:58:47 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 944BF8D0001; Mon, 18 Dec 2023 09:58:47 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 80BAB8D0008; Mon, 18 Dec 2023 09:58:47 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id 6FA288D0001 for ; Mon, 18 Dec 2023 09:58:47 -0500 (EST) Received: from smtpin26.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id 37ECAA2CC0 for ; Mon, 18 Dec 2023 14:58:47 +0000 (UTC) X-FDA: 81580245894.26.3123D8F Received: from mail.alien8.de (mail.alien8.de [65.109.113.108]) by imf26.hostedemail.com (Postfix) with ESMTP id 0FBD5140002 for ; Mon, 18 Dec 2023 14:58:44 +0000 (UTC) Authentication-Results: imf26.hostedemail.com; dkim=pass header.d=alien8.de header.s=alien8 header.b=f7Ico4zk; dmarc=pass (policy=none) header.from=alien8.de; spf=pass (imf26.hostedemail.com: domain of bp@alien8.de designates 65.109.113.108 as permitted sender) smtp.mailfrom=bp@alien8.de ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1702911525; a=rsa-sha256; cv=none; b=Ywx/oUMQA+AboXzv4AgOuWILqyPw9+PnBu4ZfdBAngkD9H2G2/cPNpJI47XtLYzCAf7exi kHYPUfQQcVY2U3l1MOtv41ErPWQypM2PEpikiiaJ6oisxw/ECBSWFyCH0uTHl6ITeYAHgn n4QHL3TMrBueDTTWdeyx0rjeeSulJaw= ARC-Authentication-Results: i=1; imf26.hostedemail.com; dkim=pass header.d=alien8.de header.s=alien8 header.b=f7Ico4zk; dmarc=pass (policy=none) header.from=alien8.de; spf=pass (imf26.hostedemail.com: domain of bp@alien8.de designates 65.109.113.108 as permitted sender) smtp.mailfrom=bp@alien8.de ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1702911525; 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=1weCWgHoOtoy2vZBHy2ouJrV4MN1BpD6yK4soKgP07A=; b=1G5DfjlvuVAoTCgA8qAxnRdruuZbGaBIiyKNGldO3VY2GJYPProFBY45nKRhYESBkhAE3a DUOhHn21KePnaaRAMHrdhLGdc8rZlrhBE5LZMB9qeg8/ACb8n3LawiFx2wXDtWV8GjnWvj 4JE61aEuq4fidWmeMRT7jztXCWEmxTc= Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.alien8.de (SuperMail on ZX Spectrum 128k) with ESMTP id 2115840E00A9; Mon, 18 Dec 2023 14:58:41 +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 duilsy3bKYSQ; Mon, 18 Dec 2023 14:58:39 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alien8.de; s=alien8; t=1702911518; bh=1weCWgHoOtoy2vZBHy2ouJrV4MN1BpD6yK4soKgP07A=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=f7Ico4zkVTqrPgNkFulLln5Nn7Rt6hd6Lducnsi8AYtG2bRm1E7fIBe6Agbk2AS6/ FBDdj+dVtsq21L4WCqfqzN77iciza6p2Aazc2xTtVR3SxGuiOp0VPWoYs+A/dgTw5b FgSNf+naMbhlKqPoTH4nYKt6j/lGJTCzRFDF4XDSqBeJbwFjcBzMZA6eR0ZnvgW5aN /N2XD1CjVWWNzuNDrtaYPgb/nDgDtai+TfUQDFIVaeu0uSEwHoXEt+3JE6DkHhBz6j wvXlKb79qjR05I27rf8pvHauSbZPWHvBhI6rsPg1l8zLgirQ22GzSLcHG+dOypn41P PcoxaCOKIRq+p6J/7+9P+8OePnsL2wBeWwV1cvApZkEYjZhj6gxrQsBbuLgucPLPdh t8RC4QYZ50vBVCiyindR7gHvpBk9/KtPZSxrkHRhlg3/rkjSjF4p4Z2DMEFrl7ydMC fmG7msrfTsjutInRMdlsQJBiQI1INizVxWIRhb+u7mGKAarSV0OH67C80Lko5LTDDe srRrnXx9sapR/7cSRyPEKGogfLs/jNmNHc7T2XI9NAIVSSFtNoxs4tYoSR8TR17OpG 6jEfc1CY0Pj+fXzA549HB2h4pmBSG3wjep4rqzlZPMZqBTnh5l17Nw0wYsSbaICG+w CkPBR5p/qZQ9y1BnQook8fHg= Received: from zn.tnic (pd95304da.dip0.t-ipconnect.de [217.83.4.218]) (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 9413440E0030; Mon, 18 Dec 2023 14:57:58 +0000 (UTC) Date: Mon, 18 Dec 2023 15:57:52 +0100 From: Borislav Petkov To: Michael Roth Cc: kvm@vger.kernel.org, linux-coco@lists.linux.dev, linux-mm@kvack.org, linux-crypto@vger.kernel.org, x86@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, 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, 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 v10 23/50] KVM: SEV: Make AVIC backing, VMSA and VMCB memory allocation SNP safe Message-ID: <20231218145752.GQZYBd8D1iJBrI3cWs@fat_crate.local> References: <20231016132819.1002933-1-michael.roth@amd.com> <20231016132819.1002933-24-michael.roth@amd.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20231016132819.1002933-24-michael.roth@amd.com> X-Rspam-User: X-Rspamd-Server: rspam06 X-Rspamd-Queue-Id: 0FBD5140002 X-Stat-Signature: 1qe8ng4ji63m9uk4cbu7yows5b9t9tkd X-HE-Tag: 1702911524-223636 X-HE-Meta: U2FsdGVkX18ScYTV+fv9Ck6mSOUviV+yLpLmqcfKFh7R3CrMZ0d2H7DeW1/K9S4TspFZLV1przzwGcX1p7oRiwo0tGPDXtqzFz3fn1tKP1KvSLLQJ280bUcZSmU5T+cwsG2AVhkxrN+JH5aH75mCdHz6mk/VWxm/96mAL5aN/ju2fbX9MrQv63bNx6Wd0AkX/fMthoUdBTEO2Kqd9S7BQuHfwvKWEr8zjSlSjl2OwbZj2a13Lw4ccvDlIVUywOaTDAXIKnUVxrAAyEr/fLngP/UACkGUUpxYGMj15aA8LgJjnEMXppWtipbgfidvdFmaRi+7XL5VnyNFxOoq1aQthaSdNkTkF1TRcnIfBItNt2JKn187aIy2LwOtn5bTfh4ULFtiBBWFoR3KIetcwKu++fCE7sXyw6oGTeINw1iKFC9Fz3oLy4ttsun4HnCYb6j1T83cvIrZOXLoe/wut6Kp6037FCb9EHWGqSrbLcyO95PHE/wyMDU1DpO0lHfmJhqyam+Y7y/Sm0sGuolYNgs7rdyKmiIfbJchR/60rhqQuFJV+2LZ4Wv7O/Qowb5sTJm/OgEe/AgOxDOIv8zN8lwcMu/TNrcu4uHpgZyqcr9Os/XiElTtuB2rRrqT2ELKj3PvF4IViePjuo0b4EPyPDJHrb05GyY97cLqL7Im71LijZfGVicOYyCqQRkgHRN2nFyWQ4mfoTK3NhrfGGZ4MlYcGpNd5TLvu8THqKGdXEpxhrETixIRyG5ismc9598w9XuoQ3ovRTgLxkhXBA6IQlzDXWsZumRRzESGJ7OrG6SlN36mZJwqMAwJD8BZqPBfKqHhM4SJ890PEql1zBUK9vkWAH3cOzOyc5oQdjqm3tZ1NmccUOpNpwIZ3udUMn4kgu8K1iNrcKiyWjrQ4XrKepLcw86AiC4fFCHc5sQ1J0w3OtX0ggiAaKU3EF+zo6667LPL9pLli8GLZxd48NwVrNB VNSFqczj LB0SslIsfWY9gmgczn36E8EgqJItuLuqk+WYHXQIXMIyBpDm+IeH3s7o9/33xex2tNowfVAjbGapv2VVrMDBNr9e9EIwdKiL2PoR03zSzuXTYWzAu85DvZUgjjSs7I9EL3H+Eud+Wp0QjKpVfFxgfMnSzxng3B0QSjNWm98dW6PEyE+ByMIZF/GyoQQhv497QKnKMtTHkb2P2ldq/UmfZH7dm7fu2bh+of0zf 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: Just typos: On Mon, Oct 16, 2023 at 08:27:52AM -0500, Michael Roth wrote: > From: Brijesh Singh > > Implement a workaround for an SNP erratum where the CPU will incorrectly > signal an RMP violation #PF if a hugepage (2mb or 1gb) collides with the > RMP entry of a VMCB, VMSA or AVIC backing page. > > When SEV-SNP is globally enabled, the CPU marks the VMCB, VMSA, and AVIC > backing pages as "in-use" via a reserved bit in the corresponding RMP > entry after a successful VMRUN. This is done for _all_ VMs, not just > SNP-Active VMs. > > If the hypervisor accesses an in-use page through a writable > translation, the CPU will throw an RMP violation #PF. On early SNP > hardware, if an in-use page is 2mb aligned and software accesses any > part of the associated 2mb region with a hupage, the CPU will "hugepage" > incorrectly treat the entire 2mb region as in-use and signal a spurious > RMP violation #PF. > > The recommended is to not use the hugepage for the VMCB, VMSA or s/recommended/recommendation/ s/the hugepage/a hugepage/ > AVIC backing page for similar reasons. Add a generic allocator that will > ensure that the page returns is not hugepage (2mb or 1gb) and is safe to "... the page returned is not a hugepage..." ... > +struct page *snp_safe_alloc_page(struct kvm_vcpu *vcpu) > +{ > + unsigned long pfn; > + struct page *p; > + > + if (!cpu_feature_enabled(X86_FEATURE_SEV_SNP)) > + return alloc_page(GFP_KERNEL_ACCOUNT | __GFP_ZERO); > + > + /* > + * Allocate an SNP safe page to workaround the SNP erratum where > + * the CPU will incorrectly signal an RMP violation #PF if a > + * hugepage (2mb or 1gb) collides with the RMP entry of VMCB, VMSA > + * or AVIC backing page. The recommeded workaround is to not use the "recommended" > + * hugepage. > + * > + * Allocate one extra page, use a page which is not 2mb aligned > + * and free the other. > + */ > + p = alloc_pages(GFP_KERNEL_ACCOUNT | __GFP_ZERO, 1); > + if (!p) > + return NULL; > + > + split_page(p, 1); > + > + pfn = page_to_pfn(p); > + if (IS_ALIGNED(pfn, PTRS_PER_PMD)) > + __free_page(p++); > + else > + __free_page(p + 1); > + > + return p; > +} -- Regards/Gruss, Boris. https://people.kernel.org/tglx/notes-about-netiquette