Received-SPF: pass (google.com: domain of linux-crypto-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Message-ID: <ab96e918-c8b7-67d5-1dfd-320264858cec@amd.com>
Date:   Tue, 27 Dec 2022 15:49:39 -0600
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101
 Thunderbird/91.2.1
Subject: Re: [PATCH Part2 v6 07/49] x86/sev: Invalid pages from direct map
 when adding it to RMP table
Content-Language: en-US
To:     Borislav Petkov <bp@alien8.de>, Michael Roth <michael.roth@amd.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, 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, marcorr@google.com,
        sathyanarayanan.kuppuswamy@linux.intel.com, alpergun@google.com,
        dgilbert@redhat.com, jarkko@kernel.org
References: <cover.1655761627.git.ashish.kalra@amd.com>
 <243778c282cd55a554af9c11d2ecd3ff9ea6820f.1655761627.git.ashish.kalra@amd.com>
 <YuFvbm/Zck9Tr5pq@zn.tnic> <20221219150026.bltiyk72pmdc2ic3@amd.com>
 <Y6DEv4QuvIfwWlCW@zn.tnic>
From:   "Kalra, Ashish" <ashish.kalra@amd.com>
In-Reply-To: <Y6DEv4QuvIfwWlCW@zn.tnic>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
MIME-Version: 1.0
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?eDR5dTF1alBmRGVqK28zTnZjVWtUWmdoMGJucEFOUWQ2aWYya0t1MHAzTVJn?=
 =?utf-8?B?Nlg3VlB5ZTVkdzdJWUQzMjcxcUZKSnJLSkpzc3RVS3RQVEFCUURKRGMycmFt?=
 =?utf-8?B?M1FmQm1zWGdxSENxa09hNjdTR1RTdkplaGY5dmhvbVpDMlI4eFduS2tMS1Jm?=
 =?utf-8?B?aGlIcmFUa3FGZFFoS3ArNW5uUzdVK21tZzQ2NXU5VEMyVENwQmZFNnNzZkxS?=
 =?utf-8?B?MnMvdWExb3dhTmR5dFlrdlRPTi9Ka1VFdEJxUDFXaEZXdTdPQ0VrV2g0QjVv?=
 =?utf-8?B?MjIxejhxckljVDJBOFpYVEtieHkwV1RMVFY4M3cvODlWYWlIL1FrR29vUDBi?=
 =?utf-8?B?b3Z3bHE2S0VNa0NRamhlUnZ6TFl5NmlNUUltUnNmQTZuVnJ4Vkk2SDR3TmI2?=
 =?utf-8?B?cmp2bmxLb3VYbWF0Z0JEaEJjZm9JWXpQNjEzQVBqbEVKYUJjK3VpZWtSQUcw?=
 =?utf-8?B?aG1xbW5WVE94aW4xaU84YXFLSElpYk1zak5rZEVtSWhMczJDd25EZzFJOFAx?=
 =?utf-8?B?MW82d3FwdG93d0xlTmJGNjZjTnVnODQxenJGbXNjVEZHeGhiaVFVN0loRUVq?=
 =?utf-8?B?M05LK2thWUJTVlFndWRjRmpiRTdyYkN6QTFiY0xjRVlMaU5kci94cGZsMnBS?=
 =?utf-8?B?VlJoUGlVTUxiY25VRjBMQ2s5cXFnYldTblpBeUlJK1RXeHFnY3RVUXNmWjdX?=
 =?utf-8?B?YUpiaS8vL0tkMGcvdm1ZTUxyc2UxNUhEb0ZiT0t5SmRKUjd3VEx2VTRNa2hP?=
 =?utf-8?B?ZEF2ZzlUMTdFajlWWThLMGNVTksrTjkvcDhobjdkUzZSMXk2MWdVZE9VcTM3?=
 =?utf-8?B?dlRyN2FLL0tPc2h6UWhWR3owWHA5aTVjSUdjVE01STZBQ0RxZ0JYcmNLR1Rm?=
 =?utf-8?B?aW1qTlBvOFRnc3NpRXBVbkxJRWVpQTczNFcydE1HbG9sRUozSFQ2blMrNmJQ?=
 =?utf-8?B?M2JCdHBYL0pTaHNPUHZoNnBqRUM4dDBhMzBiQWgrVzBvYjVtSUppUHN3bHMz?=
 =?utf-8?B?b0Q1MDIwaVRJVzNoUVhJVHVSYWFzQXQzTE51WklLQWd4cEtMdE0rVWJNMkNt?=
 =?utf-8?B?bjQ4NUZLc2lPVXM0M0ptVTVudy9aZmdvWmZpQ3d2dzdldm8zbitndGxRcWFv?=
 =?utf-8?B?QmZ0aENzeS9DYVNmTmxFY1V1a0tqUzlmTzRjTkh0aTVGK0VnYklCcHQ2NkFD?=
 =?utf-8?B?b1JHSXJ2MnJyVWF5NWZIWHFVTmkva3lEd3VTaWVWUEdLdStaZmpXSCtvUFdK?=
 =?utf-8?B?QU1lNldpTmpUNVdXRE1VdnM3bXFQTENCc3RQaEVwczdoVEx5YmpSMEh2Nkxs?=
 =?utf-8?B?Qmk0QTliM0h0K1ljdTFoamZiTTVqS2p1S2YrWmlaMXRXME1zTXNVMkI1QmUz?=
 =?utf-8?B?T3BLS2pJS0dOczdGeWU0RS9DMUJTeUNOVk1tc0xadXV4WENpdUhTZy9tbi9j?=
 =?utf-8?B?MmZwVVJySzQwaU52QzB2WnAxODJ6cVc2Tm9uQXZVT2xyNE5oUkU5ME1tdHRT?=
 =?utf-8?B?YTJUWW5uN3M1WU9kcUVmTWlFbkNCRUZkUUh2aGJPKzJOMXRuMVE1aW5yYU1r?=
 =?utf-8?B?UjNnRGRBNHRvSCttM2FOcDVXOWhOSjhVeFlNMUduZWpwRTcwcEgzcEdSMW94?=
 =?utf-8?B?cDRXeG9WUjZnZmk5WVo0NG43RTAwUDdVZmZPaTREajcyQlIvMVplRUo5dW9N?=
 =?utf-8?B?UUQrc3ZoQkxubXR4cHZpL2h3cTNmOWIvSWFYVzZWa2xHV08rWTRhWlV6dnlX?=
 =?utf-8?B?c25PNzN2Myt0TlpvZmNITElUTVdYRWloMEJWWUJYK2ZrVFFBTy9pZW5Qc3p5?=
 =?utf-8?B?MnNQb2pOYTFGb0UxVVlNSUM0bWlabUlKN1B0eFlHQ2Y2bk5hNmNBbkRIcDhN?=
 =?utf-8?B?ZVlEWi9jUlI5THFVUE5xMmlBQk1TRG56UGFsR1J3aFJJQkVEVjQxeTc1UEU3?=
 =?utf-8?B?M0tzTFRkVkt2YU1VTVM5R0tPelBaRVNwSzhHZGtiU1V4NEZ0Y3QzT0pZckZC?=
 =?utf-8?B?UHhtVUVBMlFPVDZmem5hR0p3M0R4MzQ4dTVWODEra1V2ZVUwakVyL3pRV1lC?=
 =?utf-8?B?REtWS1cydXk5Si9YTkN2V0N1RUtpcVpyZXNGaHZ4Z0xpRVAvV3pqOGFVTHRO?=
 =?utf-8?Q?9oTE3SMbuasgJqRAb1GXwtbUX?=
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-Network-Message-Id: aaa87af2-6b8d-4f55-4515-08dae854446d
X-MS-Exchange-CrossTenant-AuthSource: SN6PR12MB2767.namprd12.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 27 Dec 2022 21:49:45.1755
 (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: gGdiphVww4IuC7yXm4+Pdk1p7JdNoYlXXfUvLNMtgafGe22PI2F0ihDN1Z3dF7NI0pimDF9+ZA5ws5UP/qxWBw==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH7PR12MB5878
X-Spam-Status: No, score=-3.2 required=5.0 tests=BAYES_00,DKIM_SIGNED,
        DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,NICE_REPLY_A,RCVD_IN_DNSWL_NONE,
        RCVD_IN_MSPIKE_H2,SPF_HELO_PASS,SPF_PASS autolearn=ham
        autolearn_force=no version=3.4.6
X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on
        lindbergh.monkeyblade.net
Precedence: bulk
List-ID: <linux-crypto.vger.kernel.org>
X-Mailing-List: linux-crypto@vger.kernel.org

Hello Boris,

On 12/19/2022 2:08 PM, Borislav Petkov wrote:
> On Mon, Dec 19, 2022 at 09:00:26AM -0600, Michael Roth wrote:
>> We implemented this approach for v7, but it causes a fairly significant
>> performance regression, particularly for the case for npages > 1 which
>> this change was meant to optimize.
>>
>> I still need to dig in a big but I'm guessing it's related to flushing
>> behavior.
> 
> Well, AFAICT, change_page_attr_set_clr() flushes once at the end.
> 
> Don't you need to flush when you modify the direct map?
> 

Milan onward, there is H/W support for coherency between mappings of the 
same physical page with different encryption keys, so AFAIK, there 
should be no need to flush during page state transitions, where we 
invoke these direct map interface functions for re-mapping/invalidating 
pages.

I don't know if there is any other reason to flush after modifying
the direct map ?

Thanks,
Ashish