Date:   Thu, 6 Jan 2022 14:16:14 -0600
From:   Venu Busireddy <venu.busireddy@oracle.com>
To:     Tom Lendacky <thomas.lendacky@amd.com>
Cc:     Brijesh Singh <brijesh.singh@amd.com>,
        Dave Hansen <dave.hansen@intel.com>, x86@kernel.org,
        linux-kernel@vger.kernel.org, kvm@vger.kernel.org,
        linux-efi@vger.kernel.org, platform-driver-x86@vger.kernel.org,
        linux-coco@lists.linux.dev, linux-mm@kvack.org,
        Thomas Gleixner <tglx@linutronix.de>,
        Ingo Molnar <mingo@redhat.com>, Joerg Roedel <jroedel@suse.de>,
        "H. Peter Anvin" <hpa@zytor.com>, Ard Biesheuvel <ardb@kernel.org>,
        Paolo Bonzini <pbonzini@redhat.com>,
        Sean Christopherson <seanjc@google.com>,
        Vitaly Kuznetsov <vkuznets@redhat.com>,
        Jim Mattson <jmattson@google.com>,
        Andy Lutomirski <luto@kernel.org>,
        Dave Hansen <dave.hansen@linux.intel.com>,
        Sergio Lopez <slp@redhat.com>, Peter Gonda <pgonda@google.com>,
        Peter Zijlstra <peterz@infradead.org>,
        Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>,
        David Rientjes <rientjes@google.com>,
        Dov Murik <dovmurik@linux.ibm.com>,
        Tobin Feldman-Fitzthum <tobin@ibm.com>,
        Borislav Petkov <bp@alien8.de>,
        Michael Roth <michael.roth@amd.com>,
        Vlastimil Babka <vbabka@suse.cz>,
        "Kirill A . Shutemov" <kirill@shutemov.name>,
        Andi Kleen <ak@linux.intel.com>,
        "Dr . David Alan Gilbert" <dgilbert@redhat.com>,
        tony.luck@intel.com, marcorr@google.com,
        sathyanarayanan.kuppuswamy@linux.intel.com
Subject: Re: [PATCH v8 13/40] x86/kernel: Make the bss.decrypted section
 shared in RMP table
Message-ID: <YddODkUvhbWbhS3/@dt>
References: <20211210154332.11526-1-brijesh.singh@amd.com>
 <20211210154332.11526-14-brijesh.singh@amd.com>
 <YdSKQKSTS83cRzGZ@dt>
 <18eadf9d-8e31-0945-ccf4-2cb72b8e0dd4@amd.com>
 <acba0832-9b11-c93d-7903-fff33f740605@intel.com>
 <444b6c78-c4d3-f49c-6579-bd28ae32ca3c@amd.com>
 <YdcpnHrRoJJFWWel@dt>
 <bf226dc6-4aef-b7c2-342d-0167362272ea@amd.com>
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <bf226dc6-4aef-b7c2-342d-0167362272ea@amd.com>
MIME-Version: 1.0
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0: =?iso-8859-1?Q?0bN+LCE+xhx9kKzRy2/heSDfxpm3pVcjljzC4VE4dU/pulLZCaSltYJe4D?=
 =?iso-8859-1?Q?FyWn0YWmn7WOpoBB5HCMisOdocoWiBxDJc9YfjNWbxzjQzTd8MbYqMX/pi?=
 =?iso-8859-1?Q?3lSpaQq0FwqVvS44ZpSRR9pPWE4B3GuEqyNkq5OWJdyTb3smX1+JvFjmMt?=
 =?iso-8859-1?Q?Mwo3rgoQN0ONuPxAfUVanbkGf5oMxcfMh3K1G1l/zt2YTjsPwlBxGmmHuo?=
 =?iso-8859-1?Q?VQ0RJ9OJdgR7+azKg7gRnu9seTZZAL2w7StxxmQQZ5rmj7BoDLkspebGit?=
 =?iso-8859-1?Q?w8Kq3l99rmQ4aSCX+/72pFkMMoGtXmFNRcFopNS1t+HCMOkju8nUttlDA1?=
 =?iso-8859-1?Q?4w/5lxchsn6rrDDuMUEhynYBvUyJgGHIy794mrWHVQTCkAOM1raFfClQmh?=
 =?iso-8859-1?Q?HVlcMvfDJ9H2a9Q6UrifLXvabuyDCMa0NKJ1/4ZB2rZ+eitH1YLPxsoGHQ?=
 =?iso-8859-1?Q?Q4b787v0NDpROq3EC3ktXG9mz3kFpet8Ko54MkXx37p2ly010LAZIwn3i7?=
 =?iso-8859-1?Q?zB2G7DdM2+6Krm4kBllTYtcrDX+jAstLyOLCyDJleeWT0TZ7B/PdEaDcWd?=
 =?iso-8859-1?Q?W4lNx5oG5n/6sWjpPweTlOVdT/WsjC4jUWjUJq9lqyI5WlCcgabarvMxMC?=
 =?iso-8859-1?Q?5E7P5DWmjGmyGEHGu2mKAcQdObCCqAeAnENes8ZWwsrCrsQobPI8DH6tpq?=
 =?iso-8859-1?Q?8QVPdGH8aOHitLzl+ZSce2Ha1bXSxpDaf6uVyckB6cLEKZNct6ls8Vu2Un?=
 =?iso-8859-1?Q?LRF5oEE31n7MSiJmJunPI4Yej1FpubUu2QLJSPIOM39aj96ILpiI1Zmkt3?=
 =?iso-8859-1?Q?hbMKiljftgmyhR3fRupozgqpAYtvxmZBmqwPmm5GlMC+tNZxJDS5EGq08B?=
 =?iso-8859-1?Q?7md2McR0Ra97hAKULnF1ZoCIjfAUXtNiyvECC82swWAiEy6eCuf42ZNk5r?=
 =?iso-8859-1?Q?7Ui1tJhsXLhJj9TcyWDrGgKzA4ddTza5OFtTTua2DfIvowJLKGF2CCl6ZG?=
 =?iso-8859-1?Q?YX6rUoJGHCy0LFs6hY6ODSCDj7L2Th4c37fDNRmOFjMy5Qf0n+hqRxqDhR?=
 =?iso-8859-1?Q?/I5LydYRuUAeqLXIuDv0ijwPYrvYvUMuIYogXTMMXrKCwPk40QnXUDDwO7?=
 =?iso-8859-1?Q?Og9YO6BfhxV8MNxPVgfKB1Jhk2bT8Kc/jNNAaNDf3/zqnvhYiI9cqq1fV+?=
 =?iso-8859-1?Q?4TNUHAlW7KIGA17hxXVCXKmAqhsEYAyJRYmBOxLmra9e8aWzMF9ZipBB4O?=
 =?iso-8859-1?Q?5rEWkStPHiiLcK2yRZC/xxNyj6kkGiOkdq1WCjHAbxEus8cqhDY2mSYtxO?=
 =?iso-8859-1?Q?QdybdNwLWyP+wdcheLhj4thK0a7PZ5xS3QzALiMnJPEx7PmGx/WuLRgWPq?=
 =?iso-8859-1?Q?/xtRGMhwNHOfYfkM4XZLV+qXyDuPiLRPnrOEwrBOmBA4izK4I7B4SqcP23?=
 =?iso-8859-1?Q?5ONWij6NhtCd3zv6GgmfpM74LWr/ytmYZ2wciSSZqWsUht4sK4pEx+m19V?=
 =?iso-8859-1?Q?FtU9kxFwa3rOTthhPsirL/SjQBbV9cDv2QCO3JhbrKVoqlcsilAh/J3kBo?=
 =?iso-8859-1?Q?MfEgP0GJ51LvYwnDVtwR2ylTmFbQP8zoji2llJSjXqnUsEp4djIP6PjOdg?=
 =?iso-8859-1?Q?jUG7GOYr3wVX96Bvf55l0mr3Yod0ZlKylMD47groISeCps0o3X6hDOa4ry?=
 =?iso-8859-1?Q?T5tQ2zVw/guFq4LuEcmezGQztBqHPoi66pSYNR7GQtFianGQLZXXYoyNA+?=
 =?iso-8859-1?Q?ZBog=3D=3D?=
X-OriginatorOrg: oracle.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 74835bd8-7f7e-448d-d5fa-08d9d151692d
X-MS-Exchange-CrossTenant-AuthSource: SN6PR10MB2576.namprd10.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 06 Jan 2022 20:16:23.7713
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 4e2c6054-71cb-48f1-bd6c-3a9705aca71b
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: S+Z9t/J21TZgfmUR4cIyVpGoQM2f/RxY5AMrhBoH7b/bpvqq92xkEhYd3eZqa9ceSbrjQeC4710LD/r4ZlQmZAj1Ks08lOA4XMzDKJvEX6U=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SA2PR10MB4538
X-Proofpoint-Virus-Version: vendor=nai engine=6300 definitions=10219 signatures=668683
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0
 mlxlogscore=999 adultscore=0 phishscore=0 mlxscore=0 spamscore=0
 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1
 engine=8.12.0-2110150000 definitions=main-2201060128
X-Proofpoint-GUID: Ry7lmRHFKzyc3CqFEqePQR18BlOK-9Z1
X-Proofpoint-ORIG-GUID: Ry7lmRHFKzyc3CqFEqePQR18BlOK-9Z1
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

On 2022-01-06 13:06:13 -0600, Tom Lendacky wrote:
> On 1/6/22 11:40 AM, Venu Busireddy wrote:
> > On 2022-01-05 15:39:22 -0600, Brijesh Singh wrote:
> > > 
> > > 
> > > On 1/5/22 2:27 PM, Dave Hansen wrote:
> > > > On 1/5/22 11:52, Brijesh Singh wrote:
> > > > > > >  ????????? for (; vaddr < vaddr_end; vaddr += PMD_SIZE) {
> > > > > > > +??????????? /*
> > > > > > > +???????????? * When SEV-SNP is active then transition the
> > > > > > > page to shared in the RMP
> > > > > > > +???????????? * table so that it is consistent with the page
> > > > > > > table attribute change.
> > > > > > > +???????????? */
> > > > > > > +??????????? early_snp_set_memory_shared(__pa(vaddr),
> > > > > > > __pa(vaddr), PTRS_PER_PMD);
> > > > > > 
> > > > > > Shouldn't the first argument be vaddr as below?
> > > > > 
> > > > > Nope, sme_postprocess_startup() is called while we are fixing the
> > > > > initial page table and running with identity mapping (so va == pa).
> > > > 
> > > > I'm not sure I've ever seen a line of code that wanted a comment so badly.
> > > 
> > > The early_snp_set_memory_shared() call the PVALIDATE instruction to clear
> > > the validated bit from the BSS region. The PVALIDATE instruction needs a
> > > virtual address, so we need to use the identity mapped virtual address so
> > > that PVALIDATE can clear the validated bit. I will add more comments to
> > > clarify it.
> > 
> > Looking forward to see your final comments explaining this. I can't
> > still follow why, when PVALIDATE needs the virtual address, we are doing
> > a __pa() on the vaddr.
> 
> It's because of the phase of booting that the kernel is in. At this point,
> the kernel is running in identity mapped mode (VA == PA). The
> __start_bss_decrypted address is a regular kernel address, e.g. for the
> kernel I'm on it is 0xffffffffa7600000. Since the PVALIDATE instruction
> requires a valid virtual address, the code needs to perform a __pa() against
> __start_bss_decrypted to get the identity mapped virtual address that is
> currently in place.

Perhaps  my confusion stems from the fact that __pa(x) is defined either
as "((unsigned long ) (x))" (for the cases where paddr and vaddr are
same), or as "__phys_addr((unsigned long )(x))", where a vaddr needs to
be converted to a paddr. If the paddr and vaddr are same in our case,
what exactly is the _pa(vaddr) doing to the vaddr?

Venu