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 mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 8A5D0C433FE for ; Fri, 15 Oct 2021 18:05:55 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 152AE61244 for ; Fri, 15 Oct 2021 18:05:54 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 152AE61244 Authentication-Results: mail.kernel.org; dmarc=fail (p=reject dis=none) header.from=google.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=kvack.org Received: by kanga.kvack.org (Postfix) id 5A4B16B0071; Fri, 15 Oct 2021 14:05:54 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 57A73900003; Fri, 15 Oct 2021 14:05:54 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 469BF900002; Fri, 15 Oct 2021 14:05:54 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0045.hostedemail.com [216.40.44.45]) by kanga.kvack.org (Postfix) with ESMTP id 3513C6B0071 for ; Fri, 15 Oct 2021 14:05:54 -0400 (EDT) Received: from smtpin25.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay03.hostedemail.com (Postfix) with ESMTP id EB63C8249980 for ; Fri, 15 Oct 2021 18:05:53 +0000 (UTC) X-FDA: 78699450186.25.65D8710 Received: from mail-pg1-f179.google.com (mail-pg1-f179.google.com [209.85.215.179]) by imf08.hostedemail.com (Postfix) with ESMTP id 4A28530000AA for ; Fri, 15 Oct 2021 18:05:52 +0000 (UTC) Received: by mail-pg1-f179.google.com with SMTP id r2so9247632pgl.10 for ; Fri, 15 Oct 2021 11:05:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=6aKaUBfmZ/RDXszMaOimAv4KMW/OyS3sPGtjs8O2E34=; b=GVmzuU15JAJiFkhxCvlybvv8JQ/weN1u6H5X2ykdGO0SbPC2oh+6v6cVgvlO570SQt 3GkvfNVzAqWl8zPNWSHbY7njqG6CewmKP4h1XOj6yKnHOyQYUzyjQPvU2OuC15dfq4Hi VN3x/O+P0ilrNaIVGJ68Ygk351wgrsLm7ndELutEZZrw8z+cY1yzXMgBMy/pBci3EOyl ulcHWdF/9vBkEsUgkf7h44ja1u6SEY2tkk+eSi5LWgBg9XB/icMRuY+GRaP+xW3MrzGB XuNyraHQEXo08aqdnameuEFfd5qdBGYdt1wmlmW6lyc7tCbSiQ7jQ3umV9arDxtAw+lt E+OQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=6aKaUBfmZ/RDXszMaOimAv4KMW/OyS3sPGtjs8O2E34=; b=iLR39VQX1MPgSM+7ZkBkTkO2xFssdZ+aJYDfCy4JOcupaMDjKm+uk9A3fE+sCaa1NV CWvF1BKHkp/L3/zb8W4iwqmw53nbITrPyfMPFcFGhJhgWFQJTjiGdT2MPNyQls6iuwBv 9fsWs6wxGffmKbvg/WTAun8sl3wS8ZrJXVdPUQ1tWNW+OnQFNtbSHY6WhTCuGXxhCNis 3i9EJc+uWWg5u5mO82M/1/e/izwTw5zs7mQ29UfD75QCExXIRsyQpx47cR/mdplZVWaA Suqa0wxVGCm/Tq0KHdqgCmkD1LkvX0i8hxL9uxgITQcuEAEIkl4weXJMwUYf0DmtzJpy Z60A== X-Gm-Message-State: AOAM5318kePMFTdXYuXsAyWDh3GAlk4AeVord0/xAGgbSxzVnLnmstOO x6WkqwvK4HvFSDhdGR0GWRI4uw== X-Google-Smtp-Source: ABdhPJzz3Nh77XlAC6fmajJ34SeI4VWlWS8ZkGOVsmolRrMLTNk0lzHHckKjtlG+93CIt4Ywfy5cfA== X-Received: by 2002:a63:6a49:: with SMTP id f70mr7399062pgc.199.1634321152413; Fri, 15 Oct 2021 11:05:52 -0700 (PDT) Received: from google.com (157.214.185.35.bc.googleusercontent.com. [35.185.214.157]) by smtp.gmail.com with ESMTPSA id w15sm5543737pfc.220.2021.10.15.11.05.51 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 15 Oct 2021 11:05:51 -0700 (PDT) Date: Fri, 15 Oct 2021 18:05:47 +0000 From: Sean Christopherson To: Brijesh Singh Cc: 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, Thomas Gleixner , Ingo Molnar , Joerg Roedel , Tom Lendacky , "H. Peter Anvin" , Ard Biesheuvel , Paolo Bonzini , Vitaly Kuznetsov , Wanpeng Li , Jim Mattson , Andy Lutomirski , Dave Hansen , Sergio Lopez , Peter Gonda , Peter Zijlstra , Srinivas Pandruvada , David Rientjes , Dov Murik , Tobin Feldman-Fitzthum , Borislav Petkov , Michael Roth , Vlastimil Babka , "Kirill A . Shutemov" , Andi Kleen , tony.luck@intel.com, marcorr@google.com, sathyanarayanan.kuppuswamy@linux.intel.com Subject: Re: [PATCH Part2 v5 05/45] x86/sev: Add helper functions for RMPUPDATE and PSMASH instruction Message-ID: References: <20210820155918.7518-1-brijesh.singh@amd.com> <20210820155918.7518-6-brijesh.singh@amd.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20210820155918.7518-6-brijesh.singh@amd.com> X-Stat-Signature: rqrapjn3sm89p6m8ddt1515hwrroyoac Authentication-Results: imf08.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b=GVmzuU15; spf=pass (imf08.hostedemail.com: domain of seanjc@google.com designates 209.85.215.179 as permitted sender) smtp.mailfrom=seanjc@google.com; dmarc=pass (policy=reject) header.from=google.com X-Rspamd-Server: rspam04 X-Rspamd-Queue-Id: 4A28530000AA X-HE-Tag: 1634321152-91497 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 Fri, Aug 20, 2021, Brijesh Singh wrote: > diff --git a/arch/x86/kernel/sev.c b/arch/x86/kernel/sev.c > index f383d2a89263..8627c49666c9 100644 > --- a/arch/x86/kernel/sev.c > +++ b/arch/x86/kernel/sev.c > @@ -2419,3 +2419,75 @@ int snp_lookup_rmpentry(u64 pfn, int *level) > return !!rmpentry_assigned(e); > } > EXPORT_SYMBOL_GPL(snp_lookup_rmpentry); > + > +int psmash(u64 pfn) > +{ > + unsigned long paddr = pfn << PAGE_SHIFT; Probably better to use __pfn_to_phys()? > + int ret; > + > + if (!pfn_valid(pfn)) > + return -EINVAL; > + > + if (!cpu_feature_enabled(X86_FEATURE_SEV_SNP)) Shouldn't this be a WARN_ON_ONCE()? > + return -ENXIO; > + > + /* Binutils version 2.36 supports the PSMASH mnemonic. */ > + asm volatile(".byte 0xF3, 0x0F, 0x01, 0xFF" > + : "=a"(ret) > + : "a"(paddr) > + : "memory", "cc"); > + > + return ret; I don't like returning the raw result from hardware; it's mostly works because hardware also uses '0' for success, but it will cause confusion should hardware ever set bit 31. There are also failures that likely should never happen unless there's a kernel bug, e.g. I suspect we can do: if (WARN_ON_ONCE(ret == FAIL_INPUT)) return -EINVAL; if (WARN_ON_ONCE(ret == FAIL_PERMISSION)) return -EPERM; .... or if all errors are "impossible" if (WARN_ON_ONCE(ret)) return snp_error_code_to_errno(ret); FAIL_INUSE and FAIL_OVERLAP also need further discussion. It's not clear to me that two well-behaved callers can't encounter collisions due to the 2mb <=> 4kb interactions. If collisions between well-behaved callers are possible, then this helper likely needs some form of serialization. Either, the concurrency rules for RMP access need explicit and lengthy documentation.