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 09A47C6FA82 for ; Wed, 7 Sep 2022 05:14:23 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 028F06B0072; Wed, 7 Sep 2022 01:14:23 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id F41F96B0073; Wed, 7 Sep 2022 01:14:22 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id E08DB8D0002; Wed, 7 Sep 2022 01:14:22 -0400 (EDT) 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 D23066B0072 for ; Wed, 7 Sep 2022 01:14:22 -0400 (EDT) Received: from smtpin16.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id A587E1608C0 for ; Wed, 7 Sep 2022 05:14:22 +0000 (UTC) X-FDA: 79884123564.16.C85D290 Received: from mail-yw1-f181.google.com (mail-yw1-f181.google.com [209.85.128.181]) by imf26.hostedemail.com (Postfix) with ESMTP id 3E0E9140095 for ; Wed, 7 Sep 2022 05:14:22 +0000 (UTC) Received: by mail-yw1-f181.google.com with SMTP id 00721157ae682-344fc86d87cso102159077b3.3 for ; Tue, 06 Sep 2022 22:14:22 -0700 (PDT) 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; bh=XvX4d4lHGdhmKH0oBQwXf1eY3JxPJlcnylOzEMhTpjw=; b=HDlMGE1Dtzvgl4sx6psOG95eCP5fJubOQx5rXOyJx1TDazhk2aqRufACacOJcEYT0r osZ3Lo1Z8fPPZoaylkaghbAM0BQaZlBz1gP+hMcBo5QZ8uGeCzStYKrifJmkD25k/DiH lr7m3LWSVEvxQsKpef0k4kDU4xiwqz9lTMxviETiwgfIWuISK2zTacUHozdB4J3nXS9e F9TMLHMGlC1abNichKH/KwH+iUF/G7XgcKsT6byuUtzTCS35n5mgoqQHWBIs3qPwr01+ aBahQ5C+5fH4hUaf2XYXq92ziiDceVipoSwAWu2HLa44wmTacL94ihW+OhBWGzAAfqfC QwxQ== 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; bh=XvX4d4lHGdhmKH0oBQwXf1eY3JxPJlcnylOzEMhTpjw=; b=5tjIYV/aGheVKjfMeTL6Sh3zqu0pkO3ltEZJJvcVSFa1yyGoHWRhuiBdAnIJmr0MFf lO0wqYesPh2c5UBMQubHxE9j1vIyX9vET+e5IYsHrkvqPeFVjbb+AIotXDUG444ooM8Z heKgPn1rgZiQyb59JX/KCEM2VIXzpinp9I+0p/Xr2QEQl46f94w3nRwnv22C1u27OgHA FjgayAyd04ddPBSRq47NRPRMaZtSt55wOUwHzdv6Y7jzZYGkqXvtZc0nh3se94SvPner k5RmZBbBWFfHLSqcpI3UTMUPkmeHthh1AIQ+RX2gga4ZE19RxiEHT6dbEsXWngaI9q5J 6S/Q== X-Gm-Message-State: ACgBeo0iGe2hfGxGNd3/+p7ZF6Y/3AYOFNqrDQJirp7x6P89qM2fGgoj MvEEJxK0gEsfN6gNvUjlyYgTRniEOdAhuf3KJq3liw== X-Google-Smtp-Source: AA6agR4QILULoRsfdqtrSc/wO0dJ6FfgSjfGPULmGUF02/SC0+lfUh/gUzPfZ6OXZMwCh+VWaeeVJ4k7hm0bh5AhRgc= X-Received: by 2002:a81:66c5:0:b0:345:3b1c:26 with SMTP id a188-20020a8166c5000000b003453b1c0026mr1857526ywc.156.1662527661285; Tue, 06 Sep 2022 22:14:21 -0700 (PDT) MIME-Version: 1.0 References: <0ecb0a4781be933fcadeb56a85070818ef3566e7.1655761627.git.ashish.kalra@amd.com> <20220906150635.mhfvtl2xgdbzr7a5@amd.com> In-Reply-To: From: Marc Orr Date: Tue, 6 Sep 2022 22:14:10 -0700 Message-ID: Subject: Re: [PATCH Part2 v6 09/49] x86/fault: Add support to handle the RMP fault for user address To: "Kalra, Ashish" Cc: "Roth, Michael" , Jarkko Sakkinen , Borislav Petkov , x86 , LKML , kvm list , "linux-coco@lists.linux.dev" , Linux Memory Management List , Linux Crypto Mailing List , Thomas Gleixner , Ingo Molnar , Joerg Roedel , "Lendacky, Thomas" , "H. Peter Anvin" , Ard Biesheuvel , Paolo Bonzini , Sean Christopherson , Vitaly Kuznetsov , Jim Mattson , Andy Lutomirski , Dave Hansen , Sergio Lopez , Peter Gonda , Peter Zijlstra , Srinivas Pandruvada , David Rientjes , Dov Murik , Tobin Feldman-Fitzthum , Vlastimil Babka , "Kirill A . Shutemov" , Andi Kleen , Tony Luck , Sathyanarayanan Kuppuswamy , Alper Gun , "Dr . David Alan Gilbert" Content-Type: text/plain; charset="UTF-8" ARC-Authentication-Results: i=1; imf26.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b=HDlMGE1D; spf=pass (imf26.hostedemail.com: domain of marcorr@google.com designates 209.85.128.181 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=1662527662; a=rsa-sha256; cv=none; b=uz451M5d/ZLi+vvHclsRwTSqSz42VtmS973nt0lmFIJkeImHpdMELJ0nOPO7e/3Xiy5Xv9 rj/8mpJEvaWUM2N3AafjJrRXoYsyZpYCHAdZqNaOIZZ4dCoXTJeLoO3kyjIp890noheixN wlde//QN8nJLEfOqCsNdmeFHFV8+eFk= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1662527662; 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=XvX4d4lHGdhmKH0oBQwXf1eY3JxPJlcnylOzEMhTpjw=; b=5jBF5HKUDh6AGucs/HrYe5NUVQ96DWVehTjojnmwPOcdU38QLjewco8tmoELWow5lbm+s2 fQEIJBU/McaoddrkAynePTs25lDWLtr4poN0/u21br/gnYhoh7zqeUKr1v8WFcg+/AAnFl RS5rVbuFsyW/MHb6C4hhsBe4FESicd8= Authentication-Results: imf26.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b=HDlMGE1D; spf=pass (imf26.hostedemail.com: domain of marcorr@google.com designates 209.85.128.181 as permitted sender) smtp.mailfrom=marcorr@google.com; dmarc=pass (policy=reject) header.from=google.com X-Stat-Signature: df1be5dk9gtjai6e1jxzxymmngt5rqk9 X-Rspamd-Queue-Id: 3E0E9140095 X-Rspamd-Server: rspam09 X-Rspam-User: X-HE-Tag: 1662527662-576451 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: > >> >But I believe Jarkko's version calculates the correct mask (below), incorporating all 18 offset bits into the 1G page. > >> >>> hex(262144 -1) > >> >'0x3ffff' > >> > >> We can get this simply by doing (page_per_hpage(level)-1), but as I mentioned above this is not what we need. > > >If we actually want the 4K page, I think we would want to use the 0x3ffff mask as Marc suggested to get to the specific 4K RMP entry, which I don't think the current code is trying to do. But maybe that *should* be what we should be doing. > > Ok, I agree to get to the specific 4K RMP entry. Thanks, Michael, for a thorough and complete reply! I have to admit, there was some nuance I missed in my earlier reply. But after reading through what you wrote, I agree, always going to the 4k-entry to get the "assigned" bit and also leveraging the implementation of snp_lookup_rmpentry() to lookup the size bit in the 2M-aligned entry seems like an elegant way to code this up. Assuming this suggestion becomes the consensus, we might consider a comment in the source code to capture this discussion. Otherwise, I think I'll forget all of this the next time I'm reading this code :-). Something like: /* * The guest-assigned bit is always propagated to the paddr's respective 4k RMP * entry -- regardless of the actual RMP page size. In contrast, the RMP page * size, handled in snp_lookup_rmpentry(), is indicated by the 2M-aligned RMP * entry. */