From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from NAM11-BN8-obe.outbound.protection.outlook.com (NAM11-BN8-obe.outbound.protection.outlook.com [40.107.236.41]) by mx.groups.io with SMTP id smtpd.web11.21709.1681852151154169594 for ; Tue, 18 Apr 2023 14:09:11 -0700 Authentication-Results: mx.groups.io; dkim=pass header.i=@amd.com header.s=selector1 header.b=o3bJdbqz; spf=permerror, err=parse error for token &{10 18 %{i}._ip.%{h}._ehlo.%{d}._spf.vali.email}: invalid domain name (domain: amd.com, ip: 40.107.236.41, mailfrom: thomas.lendacky@amd.com) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=cNeU4lESRklAhgKspr8LLX0LKUo0R1TT/KAuHGDxIdu79CNnGnKGIvZPYXa8bdjnGofvgn7eTAHHsFsrnjj0ut0m7iJ3UlIzkGijCFJLgzPEw5g+HRvctVDDNeJkFE8LWod85FDnaIkg0As6Hi7B/2ZJKcB1yA0VsNUfQJBUv4+FEsVoO7cbd02hA/cKYiw3SnaZUAL35vJdDotyobgWc6X8spxNFcPzgDwS/dOqYrCabsiZEE5mktM7mbBZUaM6PpgzIu9FfoEyQSosI+jyO7KA9WlWCjmRu65qMOdbH+GNcJa6WjSf7hlivtzjoO67iNMG6FLeWs7EihzHZb30eQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=P3xr6mlxUxoVaAStKwfqHQvwTTj5fB96aIbYujZMJLk=; b=oEYj6U62ZvnfH76Bf449Mf5/JBlP/XByi8a8PtxnQ+CdLmFofiFskxTXe4Dz+mXjVSwsvYed+d/pEzdg4mnyzPOKm+I97/wuL78otnHhXck6adLmtxuJDmmCZLShE2cYLv+iUtsFrvc4UfOrHNDLbelIxIgz/2/K4dly0+pzQvG7nMmaSWBkoiLpOLbLjtLyZrBEIr8yrxhWypT3EhgWWyrMYOexcbpz0USROxzJxy4HWs16XNyIOdbiwhDZHGgqyOskRSGMP7JOnKxTHD2EZfVG51CNSLiYWTjOnmXBeDQVhSuoa0TKVRBpeIvkj12Y22G4mFuhdDu44RzreroybA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=amd.com; dmarc=pass action=none header.from=amd.com; dkim=pass header.d=amd.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=P3xr6mlxUxoVaAStKwfqHQvwTTj5fB96aIbYujZMJLk=; b=o3bJdbqzzOKTIn0dK+Acav9/p+UxvMMH2aCNsgb1HMNbZ3EmGfJoDMQ97CsgHnOiistyAPivDVdvy5tpIxD1BEgBnGUl67+FS+pNZsJEg7mzyrEiETxjaXJqUfO6+cb0rPQz3GgsHk51P8CsukGqrQpjB3Dl33DCUCTGyBs1l9k= Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=amd.com; Received: from DM4PR12MB5229.namprd12.prod.outlook.com (2603:10b6:5:398::12) by SJ1PR12MB6099.namprd12.prod.outlook.com (2603:10b6:a03:45e::13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.6298.45; Tue, 18 Apr 2023 21:06:09 +0000 Received: from DM4PR12MB5229.namprd12.prod.outlook.com ([fe80::ea32:baf8:cc85:9648]) by DM4PR12MB5229.namprd12.prod.outlook.com ([fe80::ea32:baf8:cc85:9648%6]) with mapi id 15.20.6298.045; Tue, 18 Apr 2023 21:06:09 +0000 Message-ID: Date: Tue, 18 Apr 2023 16:06:07 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.10.0 Subject: Re: [edk2-devel] [Patch V2 0/8] Use CpuPageTableLib to create and update smm page table To: "Tan, Dun" , "devel@edk2.groups.io" , "Ni, Ray" References: <1755241E6695EAE7.1885@groups.io> <2301e275-1f69-e5c0-997d-d967264aa590@amd.com> <4c5afff9-39b6-6f3a-ce05-0aadb8b004b9@amd.com> From: "Lendacky, Thomas" In-Reply-To: X-ClientProxiedBy: CH2PR16CA0016.namprd16.prod.outlook.com (2603:10b6:610:50::26) To DM4PR12MB5229.namprd12.prod.outlook.com (2603:10b6:5:398::12) Return-Path: Thomas.Lendacky@amd.com MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: DM4PR12MB5229:EE_|SJ1PR12MB6099:EE_ X-MS-Office365-Filtering-Correlation-Id: 55004935-fca1-4f96-194a-08db4050bbd6 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: jypzgZWLFASw1oWt/4dm7j5QUBwDyNNCfGer9yGa/pfnIwagFGE+cRBrGPVk0juUpUBiGggusiPDxUXekXgWMcG3cYuWqFP624kia2Jd6HqkfmZIFveJLR0xQH1O1yKcGHhwi1+MkUaOEjNhg+G31oTCJQ00dZjsifGb6NB/4vQ9GMFZ+NPuXSGEBgvZSx3N+AX1Qr5S4LHWnd7CazzE/vZ2emOu2hwduK2iR693SpkayU9t1GoFLoxZ9g/cz0lonqYmINHGYKEXUzmvVrFeXPuCEnSKVGgQG0uwKoZsugSOkIgydiJZyXY0qMRgyX5FGj0/m2lMxYHwtrR51B90i+Reh3ttoIvecPPAduEIb72P2Uw8DMU7IzWm9zLEP53R9otGyFnOvMAJOZ+aWCyE2Znwt7YvSwcMI2lpdVSQylhS4WsMt04wI13669rLxrWrIZVsgfg7c3dzVbCdPi/vFbfLsxOW9qmlII1G9yuSF0kimohEjzWjZsph8HMcwaJLpib45rnQjkIHBT0SByk8mw7BTP3neghTZyqVpWh0pEhbcNjN+iTcd3dJ0EdQTiq727khaZV1AGMdYO0i1NzBj3MDPBvt70F6TfKStxGEHlGOn4CGdzU2TQEH7vaKQd6PKi9pu2ZFUlXzucP6SH0CQSyKdYOrGTPwkq6u89mEWXw+FNwFO5qu9ibCKMcq64rQ X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:DM4PR12MB5229.namprd12.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230028)(4636009)(39860400002)(396003)(376002)(346002)(136003)(366004)(451199021)(26005)(186003)(6512007)(53546011)(41300700001)(6506007)(110136005)(86362001)(83380400001)(2616005)(66899021)(31696002)(316002)(66946007)(66476007)(66556008)(30864003)(2906002)(8676002)(8936002)(6486002)(966005)(15650500001)(19627235002)(31686004)(36756003)(38100700002)(5660300002)(478600001)(45980500001)(43740500002);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?b1BudjEyZUpLa0lVSW0yZHVEL0h3Q1MzOCtWODdOV0ZhZXgrb05jSExEOVZE?= =?utf-8?B?Wk5Ya3c4RzJ2WHBTRUpwUVBXak53bnZDTXF5S3h3UFF2YzNHa1RIM0hJYVpp?= =?utf-8?B?b0JaL2hLUGdqWUZicmlQNEJuZEVRNHB4R3JwYjVEaFArSU9VY2hTUjlqUlhi?= =?utf-8?B?djdDSDd6YzBnVk9ZZEJpMUNhSmRxMlRiMW9lYmRLWWp1WSttSmlxQUpER0dv?= =?utf-8?B?bnJpRVJKZXZmUkZSWkZweUFtOUdnME16bVYydlpvcXV0L0VLN0tBU25mUU80?= =?utf-8?B?SkFOSWNuVWhkSWlzMjh0ODVhblprRHg5WWl1KzFxSGZEajliVlVGQzA5N2J0?= =?utf-8?B?VjMxRUR2dFhZbEVQaWEzbGZwU0g2d3ZYREZ6dEhBUHpweVowcm84YWRESUpT?= =?utf-8?B?WjVMelJMYVh1R2I3ZnZWZFAyRkxONXA3UzQrRVFWYUFNbzl6WlZHbEdBbHpz?= =?utf-8?B?dUlud2dBbDNDditHcGVRU3hEQVZ4NGVXT2FibEU5elg3K1R2dUhGYmtZZENX?= =?utf-8?B?TXV3Q1N1dG55dmlqR0xwYUVuS0tBRkRKK0t1ZGtsczdaK05aUHlkd3J0UnBs?= =?utf-8?B?cWw1U282ZFRkcnR0OEprcE5scDZ0WDJocDVPdlNPWk9IZGlzMWZmd0twU1A1?= =?utf-8?B?czhtWTVEQlptZkNDTkZWMi94Q1lyNzlGRGNvNFU5Y05PbVc3YkQvVElzeTJ5?= =?utf-8?B?bWw1c0xHTmd0QnNUNGtVWFZCdnVHQUF6WUVZRWJWZTNqL0pzNnpIcWh2eWRu?= =?utf-8?B?alh0MzBaeFlnZWZuRjY4dXFvY1hzODlDY0NMRDhlZFlxcHBpUTR1bUszWC9h?= =?utf-8?B?d3BmSjBUMmJBejM3RjcwN0hnVjV1S2Y5a3RuZVd2SDZYQVZFMDFXalFMSWcr?= =?utf-8?B?M21BSkhMK0JGT0FzclhFTlRBR0F0TW1SdmlGME5LTTV6UGU4cmFycWpCbnc2?= =?utf-8?B?OVcrVEtXN3NjOS94ajJ4c1Y5USs4Qi9nWDlEV2xTbGJ4emNFbUFmNGI5MDg5?= =?utf-8?B?bk5jakpweWFpbDJSc3pmdmpCbUlTVHRpUzBqeUQydDh6OFNWdUJxR2Vuc3lZ?= =?utf-8?B?b3FMd0xqVmlYaEVoSGVEM3RuQS9XNTE0QlVJSjg0aXdBNHBicUhGMGRrQWtv?= =?utf-8?B?MUlLbzNmMXNvN1h0UHB1N2c1eDlLdGI1alJaTE9SN2JyeVdaaXNXeXhSVGhV?= =?utf-8?B?OTBNTCtVRXhrTlVnMS9zUy9Od0hrTkViOXZpZmM1aEo2SktZYW8wdVF5dWdJ?= =?utf-8?B?S01RUGQ4Sjd5cW8rdnc2dnVrR0NXQkxXSldUbXR0SlFUdmh6NnpmbnAxbVo5?= =?utf-8?B?NFBZYno3aTNQc29JZG1HMGVHWnJWZGt3eFY4L0VsTnRqbCtEMVpMeFBKMjg4?= =?utf-8?B?Q1B2VFU1TGx0WjR6TnY3MngyaGFTNEtGQllXSWxzUi9XUVE2TnFiTWNOQ0xQ?= =?utf-8?B?ekFVOWV0cU1LY2NNS0NhcDg1YWNybGJrZjJHSnNGNk5FdUdOOG1ONDFxZUxa?= =?utf-8?B?S2UwMjZIa0NIa2w1emtJek96cVNzVWFzRENpQlZscFpIa1dTaHArbXR2QzdT?= =?utf-8?B?VW9wZGFyM1BiUlpKcVpDK1M4N01JVEF6WHZrRzJJTzVPSUJXeXpoYVJHZTgz?= =?utf-8?B?SHRsTDBsSGdtRTRzVUd4VFBDbFlMbC9SMjh0WjFYaEZpSUE0dnhkR2tBZkZS?= =?utf-8?B?WE5sUFppZ3BBL2dkM2tUNzJ3VU5KZllxZGlhN0ZXL2ZVNkJUVlpaVDEzeHVl?= =?utf-8?B?OTBlM0tySFNhaUUxbENNTzNZN3dyMFFGVHJ2K2g1SkJZeUJjYkhFSmNWZ251?= =?utf-8?B?S1FPVkpqRXo1QmRhbDlNRHBCN1kyVFlDbzc1L2hoUEgyVEtyTnU1RitWL0lR?= =?utf-8?B?TkNVYTBtUCtSN2tDdUtTenk2Zk8vK09LR0VPNjlVblVmb01XWnNiK0JoMnFP?= =?utf-8?B?MUZFOExLdy9mbUpPeVpFbGcvN0ZpMXNqc2hyT0ZOQ1o5Qk9LOHRyMmVTRnFZ?= =?utf-8?B?eWFuME1yUWZ1L096NExWQnp6blZVTi9LMjAwQ21jcEtKSjlrSVdqUk55eW9K?= =?utf-8?B?b0ZGRVlDbmt4SWFVK2dTVUFBbW1Yc1pNTSs3d3R1MkR0RTN2RGcwaTZQVHFk?= =?utf-8?Q?t9Tsmwd8aQdSirylOcYl8WidV?= X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-Network-Message-Id: 55004935-fca1-4f96-194a-08db4050bbd6 X-MS-Exchange-CrossTenant-AuthSource: DM4PR12MB5229.namprd12.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 18 Apr 2023 21:06:09.8096 (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: ndH5YSGWtOmneXLQbq64oNelFZL0nj0mCC1MamsK8mKE2Dz40dFynvEnMr5ucOcGT4z+DPpJcXOVoc7v0401VA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: SJ1PR12MB6099 Content-Language: en-US Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 4/18/23 04:57, Tan, Dun wrote: > Hi Tom, > > I added a new patch in my code branch. This new patch removes the code that may apply AddressEncMask to smm page table non-leaf entries when splitting page table. > Could you please help test if this code branch works? > https://github.com/td36/edk2/tree/SmmPageTable_V2 It got further, but it still crashed: SmmInstallProtocolInterface: 47B7FA8C-F4BD-4AF6-8200-333086F0D2C8 0 GetUefiMemoryMap Patch page table start ... !!!! X64 Exception Type - 0E(#PF - Page-Fault) CPU Apic ID - 00000000 !!!! ExceptionData - 0000000000000003 I:0 R:0 U:0 W:1 P:1 PK:0 SS:0 SGX:0 RIP - 000000003FFC7744, CS - 0000000000000038, RFLAGS - 0000000000010082 RAX - 00000000FFFFFF83, RCX - 000000003FFB5C78, RDX - 0000000000000000 RBX - 000000003FC01000, RSP - 000000003FFB4790, RBP - 000000003FFB47B0 RSI - 000000003FC01000, RDI - 0000000000000000 R8 - 000000003FFB4840, R9 - 0000000000000002, R10 - 0000000000000000 R11 - 0000000000000000, R12 - 000000003FFB5C78, R13 - 000000003FFB4840 R14 - 0000000080000000, R15 - 0000000000000000 DS - 0000000000000020, ES - 0000000000000020, FS - 0000000000000020 GS - 0000000000000020, SS - 0000000000000020 CR0 - 0000000080010033, CR2 - 000000003FC01000, CR3 - 000000003FF81000 CR4 - 0000000000000668, CR8 - 0000000000000000 DR0 - 0000000000000000, DR1 - 0000000000000000, DR2 - 0000000000000000 DR3 - 0000000000000000, DR6 - 00000000FFFF0FF0, DR7 - 0000000000000400 GDTR - 000000003FFAC000 000000000000004F, LDTR - 0000000000000000 IDTR - 000000003FFAF000 00000000000001FF, TR - 0000000000000040 FXSAVE_STATE - 000000003FFB0C60 SMM exception at access (0x3FC01000) It is invoked from the instruction before IP(0x3FFC7744) in module (/root/kernels/ovmf-dun-build-Ia32X64/Build/Ovmf3264/DEBUG_GCC5/X64/UefiCpuPkg/PiSmmCpuDxeSmm/PiSmmCpuDxeSm m/DEBUG/PiSmmCpuDxeSmm.dll) Thanks, Tom > > Thanks, > Dun > > -----Original Message----- > From: devel@edk2.groups.io On Behalf Of Lendacky, Thomas via groups.io > Sent: Saturday, April 15, 2023 3:05 AM > To: devel@edk2.groups.io; Ni, Ray ; Tan, Dun > Subject: Re: [edk2-devel] [Patch V2 0/8] Use CpuPageTableLib to create and update smm page table > > On 4/14/23 12:19, Ni, Ray via groups.io wrote: >> tom, >> if the c bit is not required for non leaf page table entries, why the trunk code sets the c bit for all entities including nonleaf ones? > > Because it's effectively the correct thing to do, even though it doesn't matter. > >> >> i went back to read again the smm issue you met. you said the c bit is set for non leaf entries that caused a deference issue. But the pagetablelib code doesn't set c bit to non leaf entries. then who sets the c bit? > > I guess that's the main question, how did that get set? I haven't had the time to fully examine and follow the codepath in the pagetable library to figure out why it was set. Maybe as part of a page split? > > Thanks, > Tom > >> >> thanks, >> ray >> >> thanks, >> ray >> ________________________________ >> From: devel@edk2.groups.io on behalf of >> Lendacky, Thomas via groups.io >> Sent: Friday, April 14, 2023 9:43:52 PM >> To: Ni, Ray ; Tan, Dun ; >> devel@edk2.groups.io >> Subject: Re: [edk2-devel] [Patch V2 0/8] Use CpuPageTableLib to create >> and update smm page table >> >> On 4/14/23 00:07, Ni, Ray wrote: >>> >>> >>>> -----Original Message----- >>>> From: Tom Lendacky >>>> Sent: Friday, April 14, 2023 12:19 AM >>>> To: Tan, Dun ; devel@edk2.groups.io >>>> Cc: Ni, Ray >>>> Subject: Re: [edk2-devel] [Patch V2 0/8] Use CpuPageTableLib to >>>> create and update smm page table >>>> >>>> On 4/13/23 04:14, Tan, Dun wrote: >>>>> Hi Tom, >>>>> >>>>> Thank you for your help with testing. >>>>> For the build failure, it's because that the CpuPageTableLib >>>>> instance is >>>> added into OvmfPkg DSC in the last pacth ' OvmfPkg: Add >>>> CpuPageTableLib required by PiSmmCpuDxe'. I have moved this patch to >>>> the head of the patch set. >>>>> >>>>> For the boot failure, I think it's because that the encrypt mask >>>>> was not >>>> applied to the memory used by page table in page table non-leaf entry. >>>> Initially I thought the encrypt mask would only be applied to the >>>> leaf entry in AMD SEV feature. So I treated the encryption process >>>> as non 1:1 mapping, which only applies the encrypt mask to leaf >>>> entry. I'm also curious why the DxeIpl patch set works good. All the >>>> page table non-leaf entries are also not encrypted in the DxeIpl page table related patch set. >>>> >>>> Right, and that works for SEV. All non-leaf pagetable entries are >>>> treated as encrypted regardless of the encryption bit. Since the >>>> tables were built being mapped encrypted, the pagetable walk works >>>> when the non-leaf entries don't have the encryption bit set. In this >>>> case, though, the encryption bit is present in the non-leaf entry >>>> and that is the reason why there are issues. >>> >>> Can you point us which doc here >>> (https://www.amd.com/en/developer/sev.html) >>> says the page table is encrypted regardless the KEY_ID bits value? >>> How can the encryption engine know if a chunk of memory belongs to page table? >> >> It doesn't. For an SEV guest, when the hardware walks the pagetables, >> it will always treat the memory accesses as encrypted (see section >> 15.34.5 of the AMD APM Vol 2 at https://www.amd.com/system/files/TechDocs/24593.pdf). >> >> But, because the initial pagetables that are built to map everything >> as encrypted/private to start with (see >> OvmfPkg/ResetVector/Ia32/PageTables64.asm), only changing to shared >> when specifically requested, any memory allocated and used will be encrypted. >> Thus, when new pagetables are allocated/created in the CpuPageTableLib >> library, they will be encrypted and so everything works. And those new >> pagetables will map everything encrypted by default, except for the >> GHCB pages. If they were mapped shared when they were created, then >> the pagetable walk would fail. >> >>> >>> My understanding to SEV is any physical address field in guest page >>> table should have the KEY_ID bits set if the physical pages are >>> private to guest. Only some pages for GMCB don't have KEY_ID bits set as those are shared between guest and host. >> >> Right, the encryption bit in the leaf entry of the pagetables will >> determine the encryption mode. >> >>> >>> I thought Dun's patch works because all guest memory is marked as >>> shared because the KEY_ID bits in all entries are not set. Only some >>> pages that're used by GMCB have the KEY_ID bits set. >> >> Just the opposite, the CpuPageTableLib library marks everything >> encrypted and only clears the encryption bit for the GHCB pages. >> >> In MdeModulePkg/Core/DxeIplPeim/X64/VirtualMemory.c, the >> CreateIdentityMappingPageTables() function retrieves the encryption >> bit and saves it in AddressEncMask. AddressEncMask is then applied to >> the mapping attribute used when calling CreateOrUpdatePageTable() to >> build the initial pagetables. >> >>> >>> >>>> >>>> Here is some debug after setting PagingEntry at line 436 of >>>> UefiCpuPkg/Library/CpuPageTableLib/CpuPageTableMap.c: >>>> >>>> *** DEBUG: PageTableLibMapInLevel:437 - PagingEntry = 3FF81000 >>>> *** DEBUG: PageTableLibMapInLevel:437 - PagingEntry = 3FF80000 >>>> *** DEBUG: PageTableLibMapInLevel:437 - PagingEntry = 3FF83000 >>>> *** DEBUG: PageTableLibMapInLevel:437 - PagingEntry = 3FF81000 >>>> *** DEBUG: PageTableLibMapInLevel:437 - PagingEntry = 3FF80000 >>>> *** DEBUG: PageTableLibMapInLevel:437 - PagingEntry = 3FF83000 >>>> *** DEBUG: PageTableLibMapInLevel:437 - PagingEntry = 3FF81000 >>>> *** DEBUG: PageTableLibMapInLevel:437 - PagingEntry = 3FF80000 >>>> *** DEBUG: PageTableLibMapInLevel:437 - PagingEntry = 800003FC01000 >>> >>> Are you testing the SME or SEV? >>> My understanding is with SME, only the highest C bit should be set >>> indicating the physical page is encrypted. >> >> I am testing SEV. There is only a single bit to indicate whether a >> page is encrypted. The guest ASID is used to determine what key is >> used to decrypt the page. From a pagetable leaf entry, SME and SEV are >> equivalent, the encryption bit determines how the memory will be accessed. >> >> SME and SEV differ in how they deal with instruction fetches and >> pagetable walks, with SME obeying the encryption bit and SEV always >> performing the accesses as encrypted accesses for security. >> >> Thanks, >> Tom >> >>> >>> >>> >>>> !!!! X64 Exception Type - 0D(#GP - General Protection) CPU Apic ID >>>> - >>>> 00000000 !!!! >>>> >>>> 0x800003FC01000 isn't mapped and so it fails - I'm not exactly sure >>>> how the #PF turns into a #GP, though, maybe because the virtual >>>> address isn't canonical that point. >>>> >>>> Thanks, >>>> Tom >>>> >>>>> >>>>> I'll added another patch in my code branch to fix this issue later. >>>>> In the new >>>> commit, from the perspective of CpuPageTableLib, the whole memory >>>> can be divided into 3 categories: memory used by page table, guest >>>> private memory and guest shared memory. CpuPageTableLib will always >>>> apply the encrypt mask to memory used by page table, which means all >>>> the non-leaf page table entries are encrypted. For guest private >>>> memory, this case can be treated as non-1:1 mapping. We can apply >>>> the encrypt mask by setting the input parameter of PageTableMap() >>>> API like " Attribute.Uint64 = LinearAddress | AddressEncMask". For >>>> guest shared memory, this case can be treated as normal 1:1 mapping. >>>> I'll let you know once the new patch is ready. >>>>> >>>>> Thanks, >>>>> Dun >>>>> -----Original Message----- >>>>> From: devel@edk2.groups.io On Behalf Of >>>> Lendacky, Thomas via groups.io >>>>> Sent: Thursday, April 13, 2023 3:26 AM >>>>> To: devel@edk2.groups.io; Tan, Dun >>>>> Subject: Re: [edk2-devel] [Patch V2 0/8] Use CpuPageTableLib to >>>>> create >>>> and update smm page table >>>>> >>>>> On 4/12/23 05:17, duntan via groups.io wrote: >>>>>> Hi Tom, >>>>>> >>>>>> This patch set is to change PiSmmCpuDxeSmm code to use >>>> CpuPageTableLib to create and update SMM page table. The Pcd >>>> PcdPteMemoryEncryptionAddressOrMask is also used in PiSmmCpuDxeSmm >>>> code and the whole range covered by page table is mapped encrypted, >>>> which is different from the situation in DxeIpl module. >>>>>> So could you also help do a test to make sure the AMD SEV feature >>>>>> still >>>> works good in SMM with this patch set? >>>>>> Here is the code branch in my fork repo: >>>>>> https://github.com/td36/edk2/commits/SmmPageTable_V2 >>>>> >>>>> Hi Dun, >>>>> >>>>> I tested at the final commit of the branch and encountered a #GP >>>>> with an >>>> SEV guest. It looks like the CpuPageTableLibrary doesn't take the >>>> encryption bit into account. For example: >>>>> >>>>> Line 436 of UefiCpuPkg/Library/CpuPageTableLib/CpuPageTableMap.c >>>>> PagingEntry = (IA32_PAGING_ENTRY >>>> *)(UINTN)IA32_PNLE_PAGE_TABLE_BASE_ADDRESS (&ParentPagingEntry- >>>>> Pnle); >>>>> >>>>> This will get an address with the encryption bit set and then try >>>>> to >>>> reference it. When I clear the encryption bit, the code proceeds a >>>> bit further, but then encounters a #GP in a different location. >>>>> >>>>> So it appears that the CpuPageTableLibrary doesn't deal with the >>>> encryption bit properly. >>>>> >>>>> Also, going through a build/test of each individual patch had mixed results. >>>>> >>>>> - With the second patch in the series applied, I get a build error: >>>>> >>>>> /root/kernels/ovmf-dun-build-X64/OvmfPkg/OvmfPkgX64.dsc(...): >>>> error 4000: Instance of library class [CpuPageTableLib] is not found >>>>> in [/root/kernels/ovmf-dun-build- >>>> X64/UefiCpuPkg/PiSmmCpuDxeSmm/PiSmmCpuDxeSmm.inf] [X64] >>>>> consumed by module [/root/kernels/ovmf-dun-build- >>>> X64/UefiCpuPkg/PiSmmCpuDxeSmm/PiSmmCpuDxeSmm.inf] >>>>> >>>>> that isn't resolved until the final patch. >>>>> >>>>> Thanks, >>>>> Tom >>>>> >>>>>> >>>>>> Thanks, >>>>>> Dun >>>>>> >>>>>> -----Original Message----- >>>>>> From: devel@edk2.groups.io On Behalf Of >>>> duntan >>>>>> Sent: Wednesday, April 12, 2023 4:54 PM >>>>>> To: devel@edk2.groups.io >>>>>> Subject: [edk2-devel] [Patch V2 0/8] Use CpuPageTableLib to create >>>>>> and update smm page table >>>>>> >>>>>> In V2 patch set: >>>>>> 1.In 'Refinement to code about updating smm page table', use >>>>>> QuickSort() >>>> in BaseLib instead or PerformQuickSort() in BaseSortLib. >>>>>> 2.Remove the patch to add BaseSortLib in DSC file. >>>>>> 3.Add a new patch to add CpuPageTableLib in UefiCpuPkg.dsc. >>>>>> 4.Add a temp patch to add CpuPageTableLib in OvmfPkg dsc files for >>>>>> test(A previous patch I sent before '[Patch V2 4/8] OvmfPkg: Add >>>>>> CpuPageTableLib required by DxeIpl in DSC file' contains all the >>>>>> changes in this patch) >>>>>> >>>>>> Dun Tan (8): >>>>>> OvmfPkg: Add CpuPageTableLib required by PiSmmCpuDxe >>>>>> UefiPayloadPkg: Add CpuPageTableLib required by PiSmmCpuDxe >>>>>> UefiCpuPkg: Use CpuPageTableLib to convert SMM paging attribute. >>>>>> UefiCpuPkg/PiSmmCpuDxeSmm: Avoid setting non-present range >>>>>> to >>>> RO/NX >>>>>> UefiCpuPkg: Extern mSmmShadowStackSize in PiSmmCpuDxeSmm.h >>>>>> UefiCpuPkg: Refinement to current smm page table generation code >>>>>> UefiCpuPkg: Refinement to code about updating smm page table >>>>>> UefiCpuPkg/PiSmmCpuDxeSmm: Remove unnecessary function >>>>>> >>>>>> OvmfPkg/CloudHv/CloudHvX64.dsc | 2 +- >>>>>> OvmfPkg/OvmfPkgIa32.dsc | 3 ++- >>>>>> OvmfPkg/OvmfPkgIa32X64.dsc | 2 +- >>>>>> OvmfPkg/OvmfPkgX64.dsc | 2 +- >>>>>> UefiCpuPkg/PiSmmCpuDxeSmm/Ia32/PageTbl.c | 5 +++-- >>>>>> UefiCpuPkg/PiSmmCpuDxeSmm/Ia32/SmmFuncsArch.c | 3 +-- >>>>>> UefiCpuPkg/PiSmmCpuDxeSmm/Ia32/SmmProfileArch.c | 2 +- >>>>>> UefiCpuPkg/PiSmmCpuDxeSmm/MpService.c | 132 ----------------- >>>> -------------------------------------------------------------------- >>>> -------------------------- >>>> --------------------- >>>>>> UefiCpuPkg/PiSmmCpuDxeSmm/PiSmmCpuDxeSmm.c | 8 ++++++- >>>> - >>>>>> UefiCpuPkg/PiSmmCpuDxeSmm/PiSmmCpuDxeSmm.h | 97 >>>> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ >>>> ++------------------------------------- >>>>>> UefiCpuPkg/PiSmmCpuDxeSmm/PiSmmCpuDxeSmm.inf | 1 + >>>>>> UefiCpuPkg/PiSmmCpuDxeSmm/SmmCpuMemoryManagement.c | 629 >>>> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ >>>> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ >>>> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ >>>> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ >>>> ++++++++++++++++++++++++++++++++++++++++++-------------------------- >>>> -------------------------------------------------------------------- >>>> -------------------------- >>>> -------------------------------------------------------------------- >>>> -------------------------- >>>> -------------------------------------------------------------------- >>>> -------------------------- >>>> ----------------------------------------------- >>>>>> UefiCpuPkg/PiSmmCpuDxeSmm/SmmProfile.c | 348 >>>> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ >>>> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ >>>> +++++++++----------------------------------------------------------- >>>> +++++++++-------------------- >>>> -------------------------------------------------------------------- >>>> -------------------------- >>>> -------------------------------------------------- >>>>>> UefiCpuPkg/PiSmmCpuDxeSmm/X64/PageTbl.c | 229 >>>> ++++++++++++++++++++++++++++++-------------------------------------- >>>> ++++++++++++++++++++++++++++++-------- >>>> -------------------------------------------------------------------- >>>> -------------------------- >>>> ----------------------------------------------------------- >>>>>> UefiCpuPkg/PiSmmCpuDxeSmm/X64/SmmFuncsArch.c | 3 +-- >>>>>> UefiCpuPkg/PiSmmCpuDxeSmm/X64/SmmProfileArch.c | 19 ++------- >>>> ---------- >>>>>> UefiPayloadPkg/UefiPayloadPkg.dsc | 2 +- >>>>>> 17 files changed, 510 insertions(+), 977 deletions(-) >>>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >> >> >> >> >> >> >> >> >> >> >> >> > > > > >