Subject: Re: [v6 PATCH 00/21] x86: Enable User-Mode Instruction Prevention
To: Ricardo Neri <ricardo.neri-calderon@linux.intel.com>
References: <20170308003254.27833-1-ricardo.neri-calderon@linux.intel.com>
 <79ba0fff-4c01-2bfa-06cb-5cfc98dd710c@list.ru>
 <CALCETrX4D13Q4LRxGrQzXQCWvaRpq7sG0ws8CpB_bM4rKQ4W_A@mail.gmail.com>
 <997ba581-ecfa-b773-a48e-85b92a439836@list.ru>
 <CALCETrX87_RyEscDLLscNaE33=FEpzW0JVphZaWoJSBL5VhN0w@mail.gmail.com>
 <1489022122.131264.33.camel@ranerica-desktop>
 <a9043b85-e44c-4070-1ecc-75f653539423@list.ru>
 <CALCETrXNRHyB2NhpVAzgEh+UBFYD+uFrVJioFPwiO+dqQ9E1ww@mail.gmail.com>
 <63231222-5b42-c8c9-02f0-0afbe702d8b5@list.ru>
 <1489190396.131264.47.camel@ranerica-desktop>
 <6331deea-e9b0-fcfe-b75d-8100f37a615a@list.ru>
 <1490658399.2647.14.camel@ranerica-desktop>
 <cc490254-9c0b-e55e-6228-ad5e1f365123@list.ru>
 <1490762284.2647.24.camel@ranerica-desktop>
Cc: Andy Lutomirski <luto@amacapital.net>, Ingo Molnar <mingo@redhat.com>,
        Thomas Gleixner <tglx@linutronix.de>, "H. Peter Anvin" <hpa@zytor.com>,
        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>,
        "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
From: Stas Sergeev <stsp@list.ru>
Message-ID: <2a9c7bfd-e85c-2673-d3b5-906fe7dd8db4@list.ru>
Date: Wed, 29 Mar 2017 23:55:28 +0300
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101
 Thunderbird/45.8.0
MIME-Version: 1.0
In-Reply-To: <1490762284.2647.24.camel@ranerica-desktop>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1879
Lines: 42

29.03.2017 07:38, Ricardo Neri пишет:
>> Probably you could also remove
>> the sldt and str emulation for protected mode, because,
>> as I understand from this thread, wine does not
>> need those.
> I see. I would lean on keeping the emulation because I already
> implemented it :), for completeness, and because it is performed in a
> single switch. The bulk of the emulation code deals with operands.
But this is not for free.
As Andy said, you will then need a syscall and
a feature mask to be able to disable this emulation.
And AFAIK you haven't implemented that yet, so
there is something to consider.

>>>> You know the wine's
>>>> requirements now - they are very small. And
>>>> dosemu doesn't need anything at all but smsw.
>>>> And even smsw is very rare.
>>> But emulation is still needed for SMSW, right?
>> Likely so.
>> If you want, I can enable the logging of this command
>> and see if it is used by some of the DOS programs I have.
> It would be great if you could do that, if you don't mind.
OK, scheduled to the week-end.
I'll let you know.

>> But at least dosemu implements it, so probably it is needed.
> Right.
>
>> Of course if it is used by one of 100 DOS progs, then there
>> is an option to just add its support to dosemu2 and pretend
>> the compatibility problems did not exist. :)
> Do you mean relaying the GP fault to dosemu instead of trapping it and
> emulating it in the kernel?
Yes, that would be optimal if this does not severely break
the current setups. If we can find out that smsw is not in
the real use, we can probably do exactly that. But other
instructions are not in real use in v86 for sure, so I
wouldn't be adding the explicit test-cases to the kernel
that will make you depend on some particular behaviour
that no one may need. My objection was that we shouldn't
write tests before we know exactly how we want this to work.