From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <lersek@redhat.com>
Received-SPF: Pass (sender SPF authorized) identity=mailfrom;
 client-ip=209.132.183.28; helo=mx1.redhat.com; envelope-from=lersek@redhat.com;
 receiver=edk2-devel@lists.01.org 
Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28])
 (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 9740220886F26
 for <edk2-devel@lists.01.org>; Mon, 18 Feb 2019 05:23:31 -0800 (PST)
Received: from smtp.corp.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com
 [10.5.11.11])
 (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits))
 (No client certificate requested)
 by mx1.redhat.com (Postfix) with ESMTPS id 038EAB1EF;
 Mon, 18 Feb 2019 13:23:31 +0000 (UTC)
Received: from lacos-laptop-7.usersys.redhat.com (ovpn-120-242.rdu2.redhat.com
 [10.10.120.242])
 by smtp.corp.redhat.com (Postfix) with ESMTP id 48D1D60139;
 Mon, 18 Feb 2019 13:23:29 +0000 (UTC)
To: Jordan Justen <jordan.l.justen@intel.com>, edk2-devel@lists.01.org
Cc: Peter Fang <peter.fang@intel.com>, Maurice Ma <maurice.ma@intel.com>,
 Ard Biesheuvel <ard.biesheuvel@linaro.org>,
 Anthony Perard <anthony.perard@citrix.com>,
 Julien Grall <julien.grall@linaro.org>
References: <20190218101015.23399-1-jordan.l.justen@intel.com>
From: Laszlo Ersek <lersek@redhat.com>
Message-ID: <e0999aa5-85db-8347-99b8-c0db73647ea0@redhat.com>
Date: Mon, 18 Feb 2019 14:23:28 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101
 Thunderbird/52.9.1
MIME-Version: 1.0
In-Reply-To: <20190218101015.23399-1-jordan.l.justen@intel.com>
X-Scanned-By: MIMEDefang 2.79 on 10.5.11.11
X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16
 (mx1.redhat.com [10.5.110.28]); Mon, 18 Feb 2019 13:23:31 +0000 (UTC)
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  <edk2-devel.lists.01.org>
List-Unsubscribe: <https://lists.01.org/mailman/options/edk2-devel>,
 <mailto:edk2-devel-request@lists.01.org?subject=unsubscribe>
List-Archive: <http://lists.01.org/pipermail/edk2-devel/>
List-Post: <mailto:edk2-devel@lists.01.org>
List-Help: <mailto:edk2-devel-request@lists.01.org?subject=help>
List-Subscribe: <https://lists.01.org/mailman/listinfo/edk2-devel>,
 <mailto:edk2-devel-request@lists.01.org?subject=subscribe>
X-List-Received-Date: Mon, 18 Feb 2019 13:23:31 -0000
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit

generic comment (applies to all NASM usage I guess):

On 02/18/19 11:10, Jordan Justen wrote:

> +    mov     eax, cr0
> +    and     eax, ~(1 << 30)
> +    mov     cr0, eax

> +    mov     rax, cr0
> +    and     eax, ~(1 << 30)
> +    mov     cr0, rax

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.

- 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)

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.

I think calculating the mask with "strict dword" somehow (not exactly
sure how) would make this more readable; or else the BTR instruction would.

Opinions? (Again, pertaining to all NASM usage in edk2.)

Thanks
Laszlo