From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from NAM02-BL2-obe.outbound.protection.outlook.com (NAM02-BL2-obe.outbound.protection.outlook.com [40.107.75.47]) by mx.groups.io with SMTP id smtpd.web11.21076.1594141922238829034 for ; Tue, 07 Jul 2020 10:12:02 -0700 Authentication-Results: mx.groups.io; dkim=pass header.i=@amdcloud.onmicrosoft.com header.s=selector2-amdcloud-onmicrosoft-com header.b=QuLFjQHh; spf=none, err=SPF record not found (domain: amd.com, ip: 40.107.75.47, mailfrom: thomas.lendacky@amd.com) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=cWPQRy4iy8rLmftRPnDjke9L6OnHkoZwa2blr1x7zObGmXQ0zXhYntoX0rN4lUlmOeiJo1+/tHhUoJgszB4EF1P6tJuyHrTH3cKj48W54WPtvXp0EMkaHPtBr3D3Wquuv2ZSULNaGfdOsq7XOczuXg6c95xE+xjBAkGflbQZIVXJH5sjupnpGpk7944sBBgjMjkqQgg1IHCAW6rztq2FxxbB74+fvT+YQLv08cZQnR9kP3Cx4eZTBAXe6k3w37L4Wpl1t+WC6PHG4uN069wwwI4zH9ERrrY7w6a3bOzxPlSfMJTdn+DzL5pe+URenaX6ZSBwB3Ocyre1uJcxgtnpXQ== 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-SenderADCheck; bh=6jPvXaEoSSiCkzHT0HTPedpbTqZVFg7AYAtrUktgxIo=; b=dWBdJ/wzNwX4gz1mITS0J+DMyRkNrGDw2+cNrRmy/tpYzxwuij7YObXAdUmicWOtuHmD7V/ddDAUWUH+SpT6db9aAVQzDMq0zM4vQlZpgAjPn2INQeG5+69HVqNZXynpvS6vyDtYU4iwiiOZFO87n6tXlobDmIh/MXIDyqv75ax7QShM9w3jvter4OJ5GldwYCiAhFywYEJO9wAc11ie/N79Rw6Iwq1xLb6YIUlBdF3KivMinPOaZPgSliYTjMM755doWiGWsLRlRJzmJeMFei7VgF8oBsxRGZXHY0Z4XBKk09jRIPSVJcxzjT41BSsajMPG3s60QvcGJfCZCjpqCQ== 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=amdcloud.onmicrosoft.com; s=selector2-amdcloud-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=6jPvXaEoSSiCkzHT0HTPedpbTqZVFg7AYAtrUktgxIo=; b=QuLFjQHh2kT36bsdWWBBtJOYdKRXpXxRyA397LqAJi6rlADlvC9EtCTOuu8gSItedkN6RnWMqcApBbRyb7oQulqsX7ycjf4GRqNXCmfPJ/vqgh8M753tKt3MfNWsPPmbKqZq4ZoxM2BZy45n1LqqinVt8PHJGRqtTpzsn6E6Eyg= Authentication-Results: intel.com; dkim=none (message not signed) header.d=none;intel.com; dmarc=none action=none header.from=amd.com; Received: from DM5PR12MB1355.namprd12.prod.outlook.com (2603:10b6:3:6e::7) by DM5PR12MB1161.namprd12.prod.outlook.com (2603:10b6:3:73::16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3153.29; Tue, 7 Jul 2020 17:12:00 +0000 Received: from DM5PR12MB1355.namprd12.prod.outlook.com ([fe80::25ec:e6ba:197c:4eb0]) by DM5PR12MB1355.namprd12.prod.outlook.com ([fe80::25ec:e6ba:197c:4eb0%8]) with mapi id 15.20.3174.021; Tue, 7 Jul 2020 17:12:00 +0000 Subject: Re: [edk2-devel] [PATCH v9 08/46] UefiCpuPkg: Implement library support for VMGEXIT From: "Lendacky, Thomas" To: Laszlo Ersek , "Dong, Eric" , "devel@edk2.groups.io" Cc: Brijesh Singh , Ard Biesheuvel , "Justen, Jordan L" , "Gao, Liming" , "Kinney, Michael D" , "Ni, Ray" References: <79f21141-07c6-d63f-7680-1ef08c53ecec@amd.com> <2d5f88ec-b3c4-8beb-dd60-68640f96b0da@amd.com> <9235cfe8-d9dc-4995-afee-681e96889f88@redhat.com> <4742c21f-19b6-b4c2-ea8c-fc15fbb8170b@amd.com> Message-ID: Date: Tue, 7 Jul 2020 12:11:58 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0 In-Reply-To: <4742c21f-19b6-b4c2-ea8c-fc15fbb8170b@amd.com> X-ClientProxiedBy: SN4PR0201CA0069.namprd02.prod.outlook.com (2603:10b6:803:20::31) To DM5PR12MB1355.namprd12.prod.outlook.com (2603:10b6:3:6e::7) Return-Path: thomas.lendacky@amd.com MIME-Version: 1.0 X-MS-Exchange-MessageSentRepresentingType: 1 Received: from [10.236.30.118] (165.204.77.1) by SN4PR0201CA0069.namprd02.prod.outlook.com (2603:10b6:803:20::31) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3153.23 via Frontend Transport; Tue, 7 Jul 2020 17:11:59 +0000 X-Originating-IP: [165.204.77.1] X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-HT: Tenant X-MS-Office365-Filtering-Correlation-Id: 95a74dc8-159a-4919-970a-08d82298dc54 X-MS-TrafficTypeDiagnostic: DM5PR12MB1161: X-MS-Exchange-Transport-Forked: True X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:9508; X-Forefront-PRVS: 0457F11EAF X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: CP6HpHvQTFg6UqewKucG//6ek8ZVlN4JluCIct9Jt8ifG+tvSMw3qglIxJo5T0WIS1wm1PnsbWd9H5Vnf1uXGZKy4wErNerBNOwmkBYCOjjCwFAvFOh2Cy4WKkEztovhQu6KY7CFlVjGveN9jA6vXdDwe6vzdZH6aCa95wyE6uZF4L/KrTwXrDRvcUFgfN6SDDuR2DzH/PjeQ047PyG//QT4uFOEuCOXc43W8qWeofzGdDhJ2Q1Bea9XIu8diuZyuNTcDz3r0eHe4tS11RhSHhHDnry9AoX42ZWgkJSvFCSbMPCsVIdx7ZvUvG/r//T4MN0uIyPCLUtvepCSux+skMd8a3Pf0apmDcQdhBfnX5aUEYJXMdXOfOaxTsBFk4MaTYnCuUu0zZHhbLQHEOsYSMdxa41/DOeUgxeAN4FRKpVplYH6Cc5j30untXFy+6KDaH706UbeJnWOmcR3y4PHPzndrGz8HbkRV80CLZridRQ= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:DM5PR12MB1355.namprd12.prod.outlook.com;PTR:;CAT:NONE;SFTY:;SFS:(4636009)(366004)(39860400002)(136003)(346002)(376002)(396003)(26005)(83380400001)(16526019)(66946007)(8676002)(6486002)(66476007)(66556008)(4326008)(8936002)(36756003)(45080400002)(2616005)(53546011)(186003)(956004)(966005)(478600001)(54906003)(52116002)(86362001)(110136005)(316002)(31686004)(2906002)(5660300002)(16576012)(31696002)(43740500002)(460985005);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData: rh6CtnD1bgj/EO06FIsSZ5kB+P5mpb7ofjkqMf00jyRSFR1LJxofTAzalGkqB2VCCRpBP+z6Ne/nKWdZwCzjfiaMJqr9alew5HFHv5yoLGOU/HLG4EPtmyBrseRUIpqC+T2tsaIDM0kgaVwLU/nOgEUJa8ysh67Vg4hJaeF9MS4SmRaEkCZ5xGzUSHZx2nHRExUAxDzli8nZw6o4Wo0IWLByYQpkAPoqJbl+94rlBh6e9jDAvgQXJqIrGIgUHq5QkwXEiWXUqtcHh36YyYvhLD+i9sAUkXcY8Yxr1cZzZDufazGjlXcxkyo4ATByUKsbyUA6Qd6jJ7m6OFO2+5+8hnA7yLDHK6cu0/bBE5sZUh/UsH6wU8c//LRk0KR3syScdfuhswchszdeFET+isyxW23+V5iOLXY2j88yDEyfCpndpiovfmOQSeUA58a0KJD3NTqgAuGRxgvoNTmygvD7Vs8+vJQV8FlMSyBNM+LJFmw= X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-Network-Message-Id: 95a74dc8-159a-4919-970a-08d82298dc54 X-MS-Exchange-CrossTenant-AuthSource: DM5PR12MB1355.namprd12.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 07 Jul 2020 17:12:00.1678 (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: eC/dLwp/jnnUWYcOmdexoKUM7qb2sUrVQkdX8bzBsDSQqqXkGeoCz/1Mqsh2KLGnUXdbrkpMZzyVauFmIfrLiA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR12MB1161 Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit On 7/7/20 10:50 AM, Tom Lendacky wrote: > On 7/7/20 10:36 AM, Laszlo Ersek wrote: >> On 07/06/20 22:03, Tom Lendacky wrote: >>> On 7/2/20 2:04 AM, Dong, Eric wrote: >>>> Hi Tom, >>> >>> Hi Eric, >>> >>>> >>>> We have root cause this Mac file format issue. The patch mail from your side include extra two "=0D=0D" , and our test tool convert them to "\r\r". This is Mac file line ending format. So this issue been reported. We have updated our tool to handle this special case. >>> >>> Good to know, thanks! >>> >>>> >>>> With that change, now I met below error when use VS2015 tool chain. Can you help to fix it? >>>> >>>> Building ... g:\edk2-open-source\edk2\MdePkg\Library\PeiCoreEntryPoint\PeiCoreEntryPoint.inf [X64] >>>> PeCoffLoaderEx.c >>>> g:\edk2-open-source\edk2\OvmfPkg\Library\VmgExitLib\VmgExitVcHandler.c(386): warning C4334: '<<': result of 32-bit shift implicitly converted to 64 bits (was 64-bit shift intended?) >>>> NMAKE : fatal error U1077: '"C:\Program Files (x86)\Microsoft Visual Studio 14.0\Vc\bin\x86_amd64\cl.exe"' : return code '0x2' >> >> This is for the line >> >> Displacement *= (1 << Ext->Sib.Scale); >> >> from >> >> [edk2-devel] [PATCH v9 17/46] >> OvmfPkg/VmgExitLib: Add support for NPF NAE events (MMIO) >> >>> >>> Yup, looks like that needs to be a "1ULL <<" instead of "1 <<". >>> I have verified that fixes the issue. >> >> I disagree. >> >> At that point, Displacement is of type INT64, and it may well be a >> negative value. We definitely want to multiply it by a signed int >> (values 1, 2, 4, 8). >> >> I commented on this before. Please see: >> >> (i) my comment block (10) here -- especially comment (10c): >> >> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fedk2.groups.io%2Fg%2Fdevel%2Fmessage%2F60144&data=02%7C01%7Cthomas.lendacky%40amd.com%7Cec0cb2ad96694b66d8ff08d8228b7c8e%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637297329772337705&sdata=g%2BGooY1Sv0G7ydr11Jh%2BTXxo4Wy6ZWcT5Mq9VmWddi8%3D&reserved=0 >> >> (alternative link: >> ) >> >> (ii) and my comment here: >> >> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fedk2.groups.io%2Fg%2Fdevel%2Fmessage%2F60146&data=02%7C01%7Cthomas.lendacky%40amd.com%7Cec0cb2ad96694b66d8ff08d8228b7c8e%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637297329772337705&sdata=iNIBJCIlfEEsY37cdwUbH27tx5HvXVs3PZiOQfaGeLQ%3D&reserved=0 >> >> (alternative link: >> ). >> >> >> The compiler warning is well-meaning, but unnecessary. A 64-bit shift is >> *NOT* intended. We want to end up with one of the signed int (aka INT32) >> values 1, 2, 4 or 8. And then multiply the INT64 Displacement with that >> value. For the multiplication, the INT32 value 1, 2, 4 or 8 will be >> implicitly converted to INT64. That's entirely intentional. >> >> If we want to suppress the warning, while keeping the logic intact, we >> should employ an explicit cast: >> >> Displacement *= (INT64)(1 << Ext->Sib.Scale); > > Ok, that makes sense. I'll use the explicit cast. > >> >>> >>> One thing I noticed is that the 32-bit builds >>> (PlatformCI_OvmfPkg_Windows_VS2019_PR, Platform_CI OVMF_IA32_NOOPT and >>> Platform_CI OVMF_IA32X64_NOOPT) encounter an error: >>> >>> ERROR - Linker #2001 from SecMain.lib(SecMain.obj) : unresolved external symbol __allshl >>> ERROR - Linker #1120 from d:\a\1\s\Build\Ovmf3264\NOOPT_VS2019\IA32\OvmfPkg\Sec\SecMain\DEBUG\SecMain.dll : fatal 1 unresolved externals >>> ERROR - Compiler #1077 from NMAKE : fatal '"C:\Program Files (x86)\Microsoft Visual Studio\2019\Enterprise\VC\Tools\MSVC\14.26.28801\bin\Hostx86\x86\link.exe"' : return code '0x460' >>> >>> Any idea what is causing this error? >> >> A left-shift operator (<<) applied to a 64-bit operand is somehow >> finding its way into the 32-bit SEC build. >> >> That is indeed wrong (for such cases, we're supposed to use LShiftU64() >> from BaseLib). >> >> What I don't understand however is that all of the "<<" operator uses, >> on 64-bit operands, should already be limited to code that is *only* >> built for X64! >> >> For example, with this series applied, SecMain in OVMF consumes >> "UefiCpuPkg/Library/CpuExceptionHandlerLib/SecPeiCpuExceptionHandlerLib.inf". >> And the latter consumes VmgExitLib. >> >> But VmgExitLib is resolved to >> "UefiCpuPkg/Library/VmgExitLibNull/VmgExitLibNull.inf", in the IA32 and >> IA32X64 DSC files. This Null instance contains no left-shifts. >> >> Therefore any << operators, applied to 64-bit operands, present in >> "OvmfPkg/Library/VmgExitLib", should never be compiled for IA32 and IA32X64. >> >> So I don't know where the problematic "<<" comes from. It does not come >> from VmgExitLib, as far as I can tell. > > Yes, I don't think it's coming from VmgExitLib, either. > > I wonder if it somehow might be coming from the MSR_SEV_ES_GHCB_REGISTER > struct and the bit fields that are used within it? That code, while not > executed in non-X64 builds because SEV-ES is not active, is still built > and maybe the bit fields result in implicit shifts occurring, specifically > in SevEsProtocolFailure()? > > I'll experiment with some things and see if that is the issue. I commented out the setting of the GhcbTerminate fields in the SevEsProtocolFailure() routine of OvmfPkg/Sec/SecMain.c and the error disappeared. I'll see if changing from using UINT64 to multiple UINT32 entries fixes the problem, but I wouldn't think that the bit fields would/should cause an issue here with 32-bit builds. Thanks, Tom > > Thanks, > Tom > >> >> Thanks, >> Laszlo >>