On Fri, 2017-03-10 at 06:17 -0800, Andy Lutomirski wrote:
On Fri, Mar 10, 2017 at 3:33 AM, Stas Sergeev stsp@list.ru wrote:
10.03.2017 05:39, Andy Lutomirski пишет:
On Thu, Mar 9, 2017 at 2:10 PM, Stas Sergeev stsp@list.ru wrote:
09.03.2017 04:15, Ricardo Neri пишет:
On Wed, 2017-03-08 at 08:46 -0800, Andy Lutomirski wrote:
On Wed, Mar 8, 2017 at 8:29 AM, Stas Sergeev stsp@list.ru wrote: > > 08.03.2017 19:06, Andy Lutomirski пишет: >> >> On Wed, Mar 8, 2017 at 6:08 AM, Stas Sergeev stsp@list.ru wrote: >>> >>> 08.03.2017 03:32, Ricardo Neri пишет: >>>> >>>> These are the instructions covered by UMIP: >>>> * SGDT - Store Global Descriptor Table >>>> * SIDT - Store Interrupt Descriptor Table >>>> * SLDT - Store Local Descriptor Table >>>> * SMSW - Store Machine Status Word >>>> * STR - Store Task Register >>>> >>>> This patchset initially treated tasks running in virtual-8086
mode as a >>>> >>>> special case. However, I received clarification that DOSEMU[8]
does not >>>> >>>> support applications that use these instructions. >> >> Can you remind me what was special about it? It looks like you
still >> >> emulate them in v8086 mode. > > Indeed, sorry, I meant prot mode here. :) > So I wonder what was cited to be special about v86.
Initially my patches disabled UMIP on virtual-8086 instructions, without regards of protected mode (i.e., UMIP was always enabled). I didn't have emulation at the time. Then, I added emulation code that now covers protected and virtual-8086 modes. I guess it is not special anymore.
But isn't SLDT&friends just throw UD in v86? How does UMIP affect this? How does your patch affect this?
Er, right. Ricardo, your code may need fixing. But don't you have a test case for this?
Why would you need one? Or do you really want to allow these instructions in v86 by the means of emulation? If so - this wasn't clearly stated in the patch description, neither it was properly discussed, it seems.
What I meant was: if the patches incorrectly started making these instructions work in vm86 mode where they used to cause a vm86 exit, then that's a bug that the selftest should have caught.
Yes, this is the case. I will fix this behavior... and update the test cases.