Received-SPF: pass (google.com: domain of linux-crypto-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
Subject: Re: [PATCH Part2 v5 21/45] KVM: SVM: Make AVIC backing, VMSA and VMCB
 memory allocation SNP safe
To:     "Dr. David Alan Gilbert" <dgilbert@redhat.com>
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 <tglx@linutronix.de>,
        Ingo Molnar <mingo@redhat.com>, Joerg Roedel <jroedel@suse.de>,
        Tom Lendacky <thomas.lendacky@amd.com>,
        "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>,
        Wanpeng Li <wanpengli@tencent.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>, tony.luck@intel.com,
        marcorr@google.com, sathyanarayanan.kuppuswamy@linux.intel.com
References: <20210820155918.7518-1-brijesh.singh@amd.com>
 <20210820155918.7518-22-brijesh.singh@amd.com> <YUt8KOiwTwwa6xZK@work-vm>
 <b3f340dc-ceee-3d04-227d-741ad0c17c49@amd.com> <YUzJ1VHbSIrKYy0c@work-vm>
From:   Brijesh Singh <brijesh.singh@amd.com>
Message-ID: <21eff550-265e-cbd9-0751-73ee87049044@amd.com>
Date:   Thu, 23 Sep 2021 17:23:55 -0500
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0)
 Gecko/20100101 Thunderbird/78.14.0
In-Reply-To: <YUzJ1VHbSIrKYy0c@work-vm>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
Content-Language: en-US
MIME-Version: 1.0
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?MTJwejdOY0tya2t3a0IrbzR1T0dhMlptWkI0SDJNTk9hRXNnT2xsUUt1Nm1N?=
 =?utf-8?B?blVleTNneXlleThXMEdvT3lTa3NuTFNwRGVqcDBPeE10OS9QTkxMRHR1dnlE?=
 =?utf-8?B?Kzc5RXh1VEJSWTlGM3o5bnVuVjd3dVJPNUtQdi9xeHpkbTdDREhWMFR5VS9Z?=
 =?utf-8?B?amcyS3FLc1daUVdFUDcwa0F1UXhiNFdWWSsvSzFyUDVTODVodW5ZcitTa1hE?=
 =?utf-8?B?UnpWZUxmd1J4dkt0MVFDV3l4VXBpZjY3Q3lGVzRieEZqaFk1c3IvZWtaV1VO?=
 =?utf-8?B?TnZ3c0E4OVhxaGpycFQxUW0rYngzT2R0eCtLajJ6TGxLUE1OY0VPaVJENktm?=
 =?utf-8?B?UEQvelptV3BYNm9MOHVCcHV6ZFk4WEdjYjMrU3BsbkRvcGVYTVc1MnVmdHhZ?=
 =?utf-8?B?R2ljaHEzWU1ETTc3TXFmRG1FUlB1bDJ5dzdVenJkYTZwTUN6bEFISWRUNjJy?=
 =?utf-8?B?ZHFRcnRGY3N6anF2NEl6WGFDU0pmRVFrUkVoakc4ZXNKUGw2WEZLcGpNNkhQ?=
 =?utf-8?B?dDc3QTZOYXc5dDV2ZHFVbDZ4VkxLallhMTZldC84MVFhZFVQOGJOMmxTWjZK?=
 =?utf-8?B?K0wzbTBzWmU4RWVQdnRYQnFoUmk0SWJSdk1KQWdBRjQ0RWtwUk5JcEV4dUMv?=
 =?utf-8?B?OXZUK0RlN3J1UnR1WEdES2N3Z2pkcjFnTjE3b29uTXJyMHJjbDFSbVc4ZDVF?=
 =?utf-8?B?VHYyVDR6RnRsdzE4cUxtUUFJTnRERTcvSXlKZjJNVE1mQVRjRzVqbzJ5djhC?=
 =?utf-8?B?MjhBc2d4TlBnM2ZCdWRsTDA4SEJIcVdybGhVS205bytjN1pEQklXdkp5bDZ1?=
 =?utf-8?B?YXpRT2RpdUR5ODlOTnRXMHByN1FtR2Z0Zm0wd0VqczVLSG94d1pXeWxaK0tt?=
 =?utf-8?B?M25la2JiUHlBWFRlczFGaFhXUGNlaEp4OU0vUUExaHZHV0daMGxmUCtNV3Iv?=
 =?utf-8?B?WVNNMkRhVC9XMWNWb3FDSEJodjR1YzNNT0pzR25SOEZ2K2tRS1NGQzBQS2Yz?=
 =?utf-8?B?KzZyTXBGRDU5SmRsU0lGT1c5cXJhQmMyV2EzZ2RLWUhpdGVzZlhLbW5JckhV?=
 =?utf-8?B?SFQraCtRRkVZUHZQaFF5azAwY3plZStLVXVtYXpCUHRzQ3VXZFhvVjh2ZW5k?=
 =?utf-8?B?WnlrbnJsU3Z2QVhIQTVwdlA1cVhxNlJkMVVVRllWYkhmbnIvQ0NMbDh3amRQ?=
 =?utf-8?B?UjlIVkY5UmEwT0pGMmhNUnN4NzJMSVBpMEFKbEZ5aW5NNWdEL0VRM2VaU1NG?=
 =?utf-8?B?NFBXZFFqUE5jcXBmRjluODRCZUtvR2NkeC82dGsvOUM1aE9aWlJJSFdsaEs1?=
 =?utf-8?B?YjYvSUxtYjBhR3YzVk5VbDVINzEyZ1JCdWxhczBOTFdUZnZyNU1KSG1Eek41?=
 =?utf-8?B?Q0Z2U1dPM0c3WXVXYm95cGtIeTdWaTFWN3dDcTFNN29XMDdxS3RnUmNld2t3?=
 =?utf-8?B?YXEyTXQwMk4xcHZkdUdnRzRXcHNFNEhUQ3hxbmUzTEFwR2JBdzJuZXc4bWZX?=
 =?utf-8?B?cVV0SVJMUVZGNjRPVzAzeU1IVVNoM2JVQ1BNb2NOMmhPcEVtVjg4a09HQjZ5?=
 =?utf-8?B?OTJPcWlxaGJ1cDN6aWx5UzdDeDFvVFBPWERSM1IrMll2Y0ttTkxtbk5ZRDdK?=
 =?utf-8?B?NXRqbkVaTmdqVnd3L0NYdTRjL3ArclR6R1g0MHdXTUpFNlY3NFJ6WjJSUmV4?=
 =?utf-8?B?cXBISEhiME5Kc1hGR090cVlKR3QydktBOWFJQXNvOGgySlRGMlQwRm50bDlV?=
 =?utf-8?Q?hPA9z/mWSprYjZ4BgNqiaZU4A33ha3uHMSsynsW?=
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 751a1848-4414-414e-4f49-08d97ee0d626
X-MS-Exchange-CrossTenant-AuthSource: SN6PR12MB2718.namprd12.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 23 Sep 2021 22:23:58.3772
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: TWV3H7u1IwfjqAE6A2ncjefGMTPUE3TeKG59Z5iWbzz0rbYsSGJtJGV2ZrxDcASaXdOWMfDm2tWLKNYD723u8g==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SA0PR12MB4511
Precedence: bulk
List-ID: <linux-crypto.vger.kernel.org>
X-Mailing-List: linux-crypto@vger.kernel.org


On 9/23/21 1:39 PM, Dr. David Alan Gilbert wrote:
> * Brijesh Singh (brijesh.singh@amd.com) wrote:
>> On 9/22/21 1:55 PM, Dr. David Alan Gilbert wrote:
>>> * Brijesh Singh (brijesh.singh@amd.com) wrote:
>>>> 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" in the RMP after a successful VMRUN.  This is
>>>> done for _all_ VMs, not just SNP-Active VMs.
>>> Can you explain what 'globally enabled' means?
>> This means that SNP is enabled in  host SYSCFG_MSR.Snp=1. Once its
>> enabled then RMP checks are enforced.
>>
>>
>>> Or more specifically, can we trip this bug on public hardware that has
>>> the SNP enabled in the bios, but no SNP init in the host OS?
>> Enabling the SNP support on host is 3 step process:
>>
>> step1 (bios): reserve memory for the RMP table.
>>
>> step2 (host): initialize the RMP table memory, set the SYSCFG msr to
>> enable the SNP feature
>>
>> step3 (host): call the SNP_INIT to initialize the SNP firmware (this is
>> needed only if you ever plan to launch SNP guest from this host).
>>
>> The "SNP globally enabled" means the step 1 to 2. The RMP checks are
>> enforced as soon as step 2 is completed.
> So I think that means we don't need to backport this to older kernels
> that don't know about SNP but might run on SNP enabled hardware (1), since
> those kernels won't do step2.

Correct.

thanks