On Wed, Mar 8, 2017 at 6:08 AM, Stas Sergeev <stsp@xxxxxxx> 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. > > Yes, this is the case. > But at least in the past there was an attempt to > support SLDT as it is used by an ancient pharlap > DOS extender (currently unsupported by dosemu1/2). > So how difficult would it be to add an optional > possibility of delivering such SIGSEGV to userspace > so that the kernel's dummy emulation can be overridden? > It doesn't need to be a matter of this particular > patch set, i.e. this proposal should not trigger a > v7 resend of all 21 patches. :) But it would be useful > for the future development of dosemu2. What I'd actually like to see is a totally separate patchset that adds an inheritable (but reset on exec) per-task mask of legacy compatibility features to disable. Maybe: sys_adjust_compat_mask(int op, int word, u32 mask); op could indicate that we want to so SET, OR, AND, or READ. word would be 0 for now. It could be a prctl, too. Things in the mask could include: COMPAT_MASK0_X86_64_VSYSCALL [1] COMPAT_MASK0_X86_UMIP_FIXUP I'm sure I could think of more along these lines. Then DOSEMU (and future WINE versions, too) could just mask off X86_UMIP_FIXUP and do their own emulation [1] For those of you thinking about this and realizing that VSYSCALL readability is inherently global and not per-task, I know how to fix that for essentially no cost :) --Andy -- To unsubscribe from this list: send the line "unsubscribe linux-msdos" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
