From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received-SPF: Pass (sender SPF authorized) identity=mailfrom; client-ip=134.134.136.126; helo=mga18.intel.com; envelope-from=jordan.l.justen@intel.com; receiver=edk2-devel@lists.01.org Received: from mga18.intel.com (mga18.intel.com [134.134.136.126]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ml01.01.org (Postfix) with ESMTPS id 0596E21959CB2 for ; Tue, 19 Feb 2019 11:59:25 -0800 (PST) X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from fmsmga005.fm.intel.com ([10.253.24.32]) by orsmga106.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 19 Feb 2019 11:59:25 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.58,388,1544515200"; d="scan'208";a="321675792" Received: from mmdandap-mobl1.amr.corp.intel.com (HELO localhost) ([10.254.8.66]) by fmsmga005.fm.intel.com with ESMTP; 19 Feb 2019 11:59:24 -0800 MIME-Version: 1.0 In-Reply-To: References: <20190218101015.23399-1-jordan.l.justen@intel.com> From: Jordan Justen To: Laszlo Ersek , edk2-devel@lists.01.org Cc: Anthony Perard , Peter Fang Message-ID: <155060636442.7367.9770376016776133854@jljusten-skl> User-Agent: alot/0.8 Date: Tue, 19 Feb 2019 11:59:24 -0800 Subject: Re: [PATCH] OvmfPkg/Sec: Clear the Cache Disable flag in the CR0 register X-BeenThere: edk2-devel@lists.01.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: EDK II Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Feb 2019 19:59:26 -0000 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable On 2019-02-18 05:23:28, Laszlo Ersek wrote: > generic comment (applies to all NASM usage I guess): >=20 > On 02/18/19 11:10, Jordan Justen wrote: >=20 > > + mov eax, cr0 > > + and eax, ~(1 << 30) > > + mov cr0, eax >=20 > > + mov rax, cr0 > > + and eax, ~(1 << 30) > > + mov cr0, rax >=20 > I've read up on the << and ~ operators in the NASM documentation, and I > think the above build-time calculations of the masks are well-defined > and correct. >=20 > - bit shifts are always unsigned > - given bit position 30, ~(1 << 30) will be a value with 32 bits > - bit-neg simply flips bits (one's complement) >=20 > On the other hand, I find these NASM specifics counter-intuitive. The > expression ~(1 << 30) looks like valid C, but in C, it means a quite > different thing. Can you elaborate? I guess there might be something subtly different, but for the most part it means the same thing, right? > I think calculating the mask with "strict dword" somehow (not exactly > sure how) would make this more readable; Oh, are you saying that (1 << 30) doesn't necessarily mean we are operating on a 32-bit value? > or else the BTR instruction would. Yeah, I guess this works. > Opinions? (Again, pertaining to all NASM usage in edk2.) As always, my opinion is to avoid writing assembly code. :) We actually had a version that set this just before the decompress in SecMain.c. Then I noted that we were initializing temp-ram here, so I moved it, even though the memory init doesn't take a significant amount of time compared to the decompress. Maybe we should just do that instead? -Jordan