From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
        id S1752824AbdAZFvU (ORCPT <rfc822;w@1wt.eu>);
        Thu, 26 Jan 2017 00:51:20 -0500
Received: from mga03.intel.com ([134.134.136.65]:24654 "EHLO mga03.intel.com"
        rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP
        id S1752106AbdAZFvS (ORCPT <rfc822;linux-kernel@vger.kernel.org>);
        Thu, 26 Jan 2017 00:51:18 -0500
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.33,287,1477983600"; 
   d="scan'208";a="1099070896"
Message-ID: <1485409876.41148.49.camel@ranerica-desktop>
Subject: Re: [v3 PATCH 00/10] x86: Enable User-Mode Instruction Prevention
From: Ricardo Neri <ricardo.neri-calderon@linux.intel.com>
To: "H. Peter Anvin" <hpa@zytor.com>
Cc: Ingo Molnar <mingo@redhat.com>, Thomas Gleixner <tglx@linutronix.de>,
        Andy Lutomirski <luto@kernel.org>, Borislav Petkov <bp@suse.de>,
        Peter Zijlstra <peterz@infradead.org>,
        Andrew Morton <akpm@linux-foundation.org>,
        Brian Gerst <brgerst@gmail.com>, Chris Metcalf <cmetcalf@mellanox.com>,
        Dave Hansen <dave.hansen@linux.intel.com>,
        Paolo Bonzini <pbonzini@redhat.com>, Liang Z Li <liang.z.li@intel.com>,
        Masami Hiramatsu <mhiramat@kernel.org>, Huang Rui <ray.huang@amd.com>,
        Jiri Slaby <jslaby@suse.cz>, Jonathan Corbet <corbet@lwn.net>,
        "Michael S. Tsirkin" <mst@redhat.com>,
        Paul Gortmaker <paul.gortmaker@windriver.com>,
        Vlastimil Babka <vbabka@suse.cz>, Chen Yucong <slaoub@gmail.com>,
        Alexandre Julliard <julliard@winehq.org>,
        Fenghua Yu <fenghua.yu@intel.com>, Stas Sergeev <stsp@list.ru>,
        "Ravi V. Shankar" <ravi.v.shankar@intel.com>,
        Shuah Khan <shuah@kernel.org>, linux-kernel@vger.kernel.org,
        x86@kernel.org, linux-msdos@vger.kernel.org, wine-devel@winehq.org
Date: Wed, 25 Jan 2017 21:51:16 -0800
In-Reply-To: <98393c2c-4d1e-d8bb-b693-ec26ea919a4c@zytor.com>
References: <20170125202353.101059-1-ricardo.neri-calderon@linux.intel.com>
         <98393c2c-4d1e-d8bb-b693-ec26ea919a4c@zytor.com>
Content-Type: text/plain; charset="UTF-8"
X-Mailer: Evolution 3.10.4-0ubuntu2 
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

Hi Peter,
On Wed, 2017-01-25 at 12:34 -0800, H. Peter Anvin wrote:
> On 01/25/17 12:23, Ricardo Neri wrote:
> >  * SMSW returns the value with which the CR0 register is programmed in
> >    head_32/64.S at boot time. This is, the following bits are enabed:
> >    CR0.0 for Protection Enable, CR.1 for Monitor Coprocessor, CR.4 for
> >    Extension Type, which will always be 1 in recent processors with UMIP;
> >    CR.5 for Numeric Error, CR0.16 for Write Protect, CR0.18 for Alignment
> >    Mask. Additionally, in x86_64, CR0.31 for Paging is set.
> 
> SMSW only returns CR0[15:0], so the reference here to CR0[31:16] seems odd.

I checked again the latest version (from Dec 2016) of the Intel Software
Development Manual. The documentation for SMSW states the following:

SMSW r16 operand size 16, store CR0[15:0] in r16
SMSW r32 operand size 32, zero-extend CR0[31:0], and store in r32
SMSW r64 operand size 64, zero-extend CR0[63:0], and store in r64

When the operand is a memory location, yes, it only returns CR0[15:0]

Also, in the tests that I ran I wrote the result of SMSW to a 64-bit
register. I get 0x80050033. It seems to me that it does write as many
bits as the register operand can hold.

Am I missing something?

Thanks and BR,
Ricardo
> 
> 	-hpa
> 
>