On Fri, 2017-03-10 at 01:01 +0300, Stas Sergeev wrote:
09.03.2017 03:46, Ricardo Neri пишет:
On Wed, 2017-03-08 at 17:08 +0300, Stas Sergeev 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.
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?
I suppose a umip=noemulation kernel parameter could be added in this case.
Why? It doesn't need to be global: the app should be able to change that on its own. Note that no app currently requires this, so its just for the future, and in the future the app can start using the new API for this, if you provide one.
Right, I missed this detail. Then, yes the API should allow only one app to relay the SIGSEGV.
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.
Would dosemu2 use 32-bit processes in order to keep segmentation? If it could use 64-bit processes, emulation is not used in this case and the SIGSEGV is delivered to user space.
It does use the mix: 64bit process but some segments are 32bit for DOS code.
Do you mean that dosemu2 will start as a 64-bit process and will jump to 32-bit code segments? My emulation code should work in this case as it will use segmentation in 32-bit code descriptors. Is there anything else needed?
Thanks and BR, Ricardo