From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from us-smtp-1.mimecast.com (us-smtp-1.mimecast.com [205.139.110.120]) by mx.groups.io with SMTP id smtpd.web10.18994.1594136177204168459 for ; Tue, 07 Jul 2020 08:36:17 -0700 Authentication-Results: mx.groups.io; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=Bp8mivIL; spf=pass (domain: redhat.com, ip: 205.139.110.120, mailfrom: lersek@redhat.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1594136176; h=from:from: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:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=28w4q0MTAl/lM5FGR3IMrTlk1e8Xt30inZzzkN/tmEE=; b=Bp8mivILGu05jKCkLOYAakj/z6X91l9HJhrxtNSQMKhqGKt54+3mjXsnzdPENXWuTSEHJ6 dQ1uPcL8+nAGkWf2X77xOFMutX7ROJKDwLWMqdC0BJizvIDBGbDe0Gk8lWG18XmQBWhDwH pDehaHJXLUHtfxsKQXOGQeH7QOmFnLs= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-248-UPlVZCY5OD-NVisaE-_bqA-1; Tue, 07 Jul 2020 11:36:06 -0400 X-MC-Unique: UPlVZCY5OD-NVisaE-_bqA-1 Received: from smtp.corp.redhat.com (int-mx05.intmail.prod.int.phx2.redhat.com [10.5.11.15]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 85977106B38B; Tue, 7 Jul 2020 15:36:04 +0000 (UTC) Received: from lacos-laptop-7.usersys.redhat.com (ovpn-114-90.ams2.redhat.com [10.36.114.90]) by smtp.corp.redhat.com (Postfix) with ESMTP id 49B7873FDD; Tue, 7 Jul 2020 15:36:02 +0000 (UTC) Subject: Re: [edk2-devel] [PATCH v9 08/46] UefiCpuPkg: Implement library support for VMGEXIT To: Tom Lendacky , "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> From: "Laszlo Ersek" Message-ID: <9235cfe8-d9dc-4995-afee-681e96889f88@redhat.com> Date: Tue, 7 Jul 2020 17:36:01 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Firefox/52.0 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: X-Scanned-By: MIMEDefang 2.79 on 10.5.11.15 Authentication-Results: relay.mimecast.com; auth=pass smtp.auth=CUSA124A263 smtp.mailfrom=lersek@redhat.com X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Language: en-US Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit 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://edk2.groups.io/g/devel/message/60144 (alternative link: ) (ii) and my comment here: https://edk2.groups.io/g/devel/message/60146 (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); > > 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. Thanks, Laszlo