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 S1752528AbdAYWFu convert rfc822-to-8bit (ORCPT <rfc822;w@1wt.eu>);
        Wed, 25 Jan 2017 17:05:50 -0500
Received: from terminus.zytor.com ([65.50.211.136]:45126 "EHLO mail.zytor.com"
        rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP
        id S1752203AbdAYWFs (ORCPT <rfc822;linux-kernel@vger.kernel.org>);
        Wed, 25 Jan 2017 17:05:48 -0500
From: "H. Peter Anvin" <hpa@zytor.com>
Message-Id: <201701252204.v0PM4bAB004396@mail.zytor.com>
Date: Wed, 25 Jan 2017 14:04:30 -0800
User-Agent: K-9 Mail for Android
In-Reply-To: <CALCETrVhF3d6V0tNoH4bXANF9e-gnbG8-HwAOgHwxibv965pZQ@mail.gmail.com>
References: <20170125202353.101059-1-ricardo.neri-calderon@linux.intel.com> <20170125202353.101059-6-ricardo.neri-calderon@linux.intel.com> <CALCETrVhF3d6V0tNoH4bXANF9e-gnbG8-HwAOgHwxibv965pZQ@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain;
 charset=utf-8
Content-Transfer-Encoding: 8BIT
Subject: Re: [v3 PATCH 05/10] x86/insn-kernel: Add support to resolve 16-bit addressing encodings
To: Andy Lutomirski <luto@amacapital.net>,
        Ricardo Neri <ricardo.neri-calderon@linux.intel.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" <linux-kernel@vger.kernel.org>,
        X86 ML <x86@kernel.org>, linux-msdos@vger.kernel.org,
        wine-devel@winehq.org, Adam@zytor.com
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

Buchbinder <adam.buchbinder@gmail.com>,Colin Ian King <colin.king@canonical.com>,Lorenzo Stoakes <lstoakes@gmail.com>,Qiaowei Ren <qiaowei.ren@intel.com>,Arnaldo Carvalho de Melo <acme@redhat.com>,Adrian Hunter <adrian.hunter@intel.com>,Kees Cook <keescook@chromium.org>,Thomas Garnier <thgarnie@google.com>,Dmitry Vyukov <dvyukov@google.com>
From: hpa@zytor.com
Message-ID: <18E8698F-6C60-4B98-AE73-C371184C5135@zytor.com>

On January 25, 2017 1:58:27 PM PST, Andy Lutomirski <luto@amacapital.net> wrote:
>On Wed, Jan 25, 2017 at 12:23 PM, Ricardo Neri
><ricardo.neri-calderon@linux.intel.com> wrote:
>> Tasks running in virtual-8086 mode will use 16-bit addressing form
>> encodings as described in the Intel 64 and IA-32 Architecture
>Software
>> Developer's Manual Volume 2A Section 2.1.5. 16-bit addressing
>encodings
>> differ in several ways from the 32-bit/64-bit addressing form
>encodings:
>> the r/m part of the ModRM byte points to different registers and, in
>some
>> cases, addresses can be indicated by the addition of the value of two
>> registers. Also, there is no support for SiB bytes. Thus, a separate
>> function is needed to parse this form of addressing.
>>
>> Furthermore, virtual-8086 mode tasks will use real-mode addressing.
>This
>> implies that the segment selectors do not point to a segment
>descriptor
>> but are used to compute logical addresses. Hence, there is a need to
>> add support to compute addresses using the segment selectors. If
>segment-
>> override prefixes are present in the instructions, they take
>precedence.
>>
>> Lastly, it is important to note that when a tasks is running in
>virtual-
>> 8086 mode and an interrupt/exception occurs, the CPU pushes to the
>stack
>> the segment selectors for ds, es, fs and gs. These are accesible via
>the
>> struct kernel_vm86_regs rather than pt_regs.
>>
>> Code for 16-bit addressing encodings is likely to be used only by
>virtual-
>> 8086 mode tasks. Thus, this code is wrapped to be built only if the
>> option CONFIG_VM86 is selected.
>
>That's not true.  It's used in 16-bit protected mode, too.  And there
>are (ugh!) six possibilities:
>
> - Normal 32-bit protected mode.  This should already work.
> - Normal 64-bit protected mode.  This should also already work.  (I
>forget whether a 16-bit SS is either illegal or has no effect in this
>case.)
> - Virtual 8086 mode
> - Normal 16-bit protected mode, used by DOSEMU and Wine.  (16-bit CS,
>16-bit address segment)
> - 16-bit CS, 32-bit address segment.  IIRC this might be used by some
>32-bit DOS programs to call BIOS.
>- 32-bit CS, 16-bit address segment.  I don't know whether anything
>uses this.
>
>I don't know if anything you're doing cares about SS's, DS's, etc.
>size, but I suspect you'll need to handle 16-bit CS.

Only the CS bitness matters for the purpose of addressing modes; the SS bitness (which has no effect in 64-bit mode) only matters for implicit stack references unless I'm completely out to sea.
-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.