With -I "cpu_vm_dpmi native" on Linux kernel 6.1.0-9 (Debian 12) RN and RM don't work about dosemu2 HOT 34 CLOSED

So on which kernel mmx worked?

from dosemu2.

$ uname -srvmpio
Linux 4.19.0 #1 SMP Thu Dec 15 20:31:06 MSK 2022 x86_64 unknown unknown GNU/Linux

But according to https://www.hosteurope.de/faq/server/virtual-server/kernel-version this is actually an older kernel with backports, "Virtual Server 8.3: 3.10.0".

from dosemu2.

Bart, could you please take a look
at what's going on here? I don't think
I can review that code.
EMU_X86_FXSR_MAGIC is defined as... 0??
How is so?

from dosemu2.

Ok, Bart is unavailable.
@ecm-pushbx in dnative.c:151 you can see this:
if ((scp->fpregs->status >> 16) == EMU_X86_FXSR_MAGIC)
This is a condition when we use mmx.
Although EMU_X86_FXSR_MAGIC is
defined as 0, which is very suspicious.
Could you please find out the real value
of scp->fpregs->status on both good
and bad systems?

from dosemu2.

But this line is under #ifndef __x86_64__

So I expect it would never be used?

from dosemu2.

Yes, good point.
So both MMX and STx contain zeros?
Please show the same output from good
kernel.

from dosemu2.

Just output of dosemu2 running these tests on the server?

https://pushbx.org/ecm/test/20230708/goodmmx.txt and https://pushbx.org/ecm/test/20230708/goodf.txt

from dosemu2.

More recent dosemu2 gives a message about using native DPMI, also on the server. Data output is the same: https://pushbx.org/ecm/test/20230708/goodmmx2.txt and https://pushbx.org/ecm/test/20230708/goodf2.txt

from dosemu2.

Can you write a small test-case
(exe or com) that sets the mmx,
then eg does hlt and then prints
its content? Maybe this can be
reproduced locally.

from dosemu2.

I can prepare something next week. However, it will have to be based on one of the DPMI examples as MMX is only supported in PM.

from dosemu2.

Then you can do the ST0 test-case,
which presumably is possible in RM?

from dosemu2.

I can have a look later (maybe tomorrow). Note that MMX uses x87 registers st0 to st7 (aliased by mm0 - mm7), and not the SSE register set (xmm0 - xmm7/15), so EMU_X86_FXSR_MAGIC should be irrelevant here.

from dosemu2.

The passed (goodmmx) testcase actually uses an older dosemu2, so it's likely a regression. Most likely the newer dosemu2 will also give similar failures on the older kernel.

I should have another careful look at FPU state, most likely the DPMI (native)FPU state isn't copied to the vm86 (emulated) FPU state.

from dosemu2.

so EMU_X86_FXSR_MAGIC should be irrelevant here.

Maybe, but please explain why its 0. :)

from dosemu2.

Maybe, but please explain why its 0. :)

it's 0 because the kernel (X86_FXSR_MAGIC) has it as 0 as well.
The magic field is set to 0xffff on old CPUs without fxsr.

from dosemu2.

The passed (goodmmx) testcase actually uses an older dosemu2, so it's likely a regression. Most likely the newer dosemu2 will also give similar failures on the older kernel.

I checked building the older revision on my local system (the "Linux 6.1.0-9-amd64") and it fails in the same way it seems. These are the commands I used:

git clone https://github.com/dosemu2/dosemu2 dosemu2-4beffeff4
cd dosemu2-4beffeff4/
git checkout 4beffeff4
./autogen.sh 
./default-configure --disable-fdpp
make
find -iname dosemu

And then: ~/proj/dosemu2-4beffeff4/2.0-pre9/bin/dosemu -dumb -td -kt -K "$PWD" -E "lcdebugx.com /c=ytestmmx.sld dpmimini.com" -I "cpu_vm_dpmi native"

from dosemu2.

Is o32 fnsave supposed to reset the state?

from dosemu2.

Uploaded a test program to https://pushbx.org/ecm/test/20230723/

dpmimmx.asm is the test program. dpmimmx.com is the binary. It tries to enter PM, detect MMX, finit things, write to mm0 using movq, read the register back using movq, then dump using o32 fnsave twice, then read back the register using movq once more.

https://pushbx.org/ecm/test/20230723/mmxbad.txt is the bad local dosemu2. I used the same dosemu2 revision as on the server for this, but it doesn't make a difference compared to my original build (Build 2.0pre9-dev-20230704-1320-g3b250d8d0). https://pushbx.org/ecm/test/20230723/mmxbad.log is the log.

Likewise https://pushbx.org/ecm/test/20230723/mmxgood.txt and https://pushbx.org/ecm/test/20230723/mmxgood.log

from dosemu2.

It seems that the o32 fnsave resets things, even when I attempt to do o32 fldenv immediately after. The very first o32 fnsave works as expected, then I read zeroes for all the mm register values.

from dosemu2.

This is where this debugger does o32 fnsave to load the values for the "RM" command: https://hg.pushbx.org/ecm/ldebug/file/e049ceac52cb/source/rr.asm#l2878

It tries o32 fldenv afterwards: https://hg.pushbx.org/ecm/ldebug/file/e049ceac52cb/source/rr.asm#l2944

This is where the "RN" command does o32 fnsave: https://hg.pushbx.org/ecm/ldebug/file/e049ceac52cb/source/rr.asm#l2017

It tries o32 frstor afterwards: https://hg.pushbx.org/ecm/ldebug/file/e049ceac52cb/source/rr.asm#l2220

The debugger never attempts to access the x87 or MMX state or registers unless explicitly instructed using the "RM" or "RN" commands or accesses to register variables like mm0.

from dosemu2.

Protected mode breakpoint at 015Dh.
Have MMX breakpoint at 01D1h.
 
Error: MMX not supported.

What does this mean?

from dosemu2.

Protected mode breakpoint at 015Dh.
Have MMX breakpoint at 01D1h.
 
Error: MMX not supported.

What does this mean?

This means that your machine running the native DPMI code appears to not support MMX, as we try to determine by checking for CPUID then running CPUID with leaf numbers 0 and 1. Look at the test program (or lDebug) source for this test. If you really want you can try to skip the test and execute the MMX instructions anyway.

from dosemu2.

Hmm.
Hi Bart, would you like to please enhance
CPUID in kvm to go past this first?
Currently we have:

  // Use the same values as in emu-i386/simx86/interp.c
  // (Pentium 133-200MHz, "GenuineIntel")

Bad idea. :)

from dosemu2.

I don't think native DPMI should use KVM?

from dosemu2.

It doesn't, but I do. :)

from dosemu2.

kvm part is done, so now I can see
both the good and bad outputs. Which
makes sense.

from dosemu2.

Warning: Using V86 mode inside KVM
So you already use KVM.
With current fix you don't need to set dpmi
to "native", and things would works fine.

from dosemu2.

Should now be fixed, enjoy.

from dosemu2.

@stsp perhaps you fancy fixing some more FPU issues? In my #1885 PR (just rebased) I have the following failures.

ajb@calypso:/clients/common/dosemu2.git$ test/test_dos.py --require-attr=fputest PPDOSGITTestCase
Test PP-DOS-GIT  FPU (Qemu)           f2xm1     JIT_JIT                          ... ok (  1.44s)
Test PP-DOS-GIT  FPU (Qemu)           f2xm1     KVM_KVM                          ... ok (  0.82s)
Test PP-DOS-GIT  FPU (Qemu)           f2xm1  KVM_NATIVE                          ... ok (  0.78s)
Test PP-DOS-GIT  FPU (Qemu)           f2xm1     SIM_SIM                          ... FAIL
Test PP-DOS-GIT  FPU (Qemu)           fbstp     JIT_JIT                          ... ok (  0.80s)
Test PP-DOS-GIT  FPU (Qemu)           fbstp     KVM_KVM                          ... ok (  0.80s)
Test PP-DOS-GIT  FPU (Qemu)           fbstp  KVM_NATIVE                          ... ok (  0.77s)
Test PP-DOS-GIT  FPU (Qemu)           fbstp     SIM_SIM                          ... ok (  0.98s)
Test PP-DOS-GIT  FPU (Qemu)          fisttp     JIT_JIT                          ... FAIL
Test PP-DOS-GIT  FPU (Qemu)          fisttp     KVM_KVM                          ... ok (  0.76s)
Test PP-DOS-GIT  FPU (Qemu)          fisttp  KVM_NATIVE                          ... ok (  0.79s)
Test PP-DOS-GIT  FPU (Qemu)          fisttp     SIM_SIM                          ... FAIL
Test PP-DOS-GIT  FPU (Qemu)          fldcst     JIT_JIT                          ... ok (  0.77s)
Test PP-DOS-GIT  FPU (Qemu)          fldcst     KVM_KVM                          ... ok (  0.76s)
Test PP-DOS-GIT  FPU (Qemu)          fldcst  KVM_NATIVE                          ... ok (  0.76s)
Test PP-DOS-GIT  FPU (Qemu)          fldcst     SIM_SIM                          ... FAIL
Test PP-DOS-GIT  FPU (Qemu)   fp-exceptions     JIT_JIT                          ... FAIL
Test PP-DOS-GIT  FPU (Qemu)   fp-exceptions     KVM_KVM                          ... ok (  0.77s)
Test PP-DOS-GIT  FPU (Qemu)   fp-exceptions  KVM_NATIVE                          ... ok (  0.79s)
Test PP-DOS-GIT  FPU (Qemu)   fp-exceptions     SIM_SIM                          ... FAIL
Test PP-DOS-GIT  FPU (Qemu)          fpatan     JIT_JIT                          ... ok (  0.73s)
Test PP-DOS-GIT  FPU (Qemu)          fpatan     KVM_KVM                          ... ok (  0.82s)
Test PP-DOS-GIT  FPU (Qemu)          fpatan  KVM_NATIVE                          ... ok (  0.89s)
Test PP-DOS-GIT  FPU (Qemu)          fpatan     SIM_SIM                          ... ok (  0.99s)
Test PP-DOS-GIT  FPU (Qemu)          fscale     JIT_JIT                          ... ok (  0.83s)
Test PP-DOS-GIT  FPU (Qemu)          fscale     KVM_KVM                          ... ok (  0.78s)
Test PP-DOS-GIT  FPU (Qemu)          fscale  KVM_NATIVE                          ... ok (  0.82s)
Test PP-DOS-GIT  FPU (Qemu)          fscale     SIM_SIM                          ... ok (  0.95s)
Test PP-DOS-GIT  FPU (Qemu)            fxam     JIT_JIT                          ... ok (  0.84s)
Test PP-DOS-GIT  FPU (Qemu)            fxam     KVM_KVM                          ... ok (  0.79s)
Test PP-DOS-GIT  FPU (Qemu)            fxam  KVM_NATIVE                          ... ok (  0.88s)
Test PP-DOS-GIT  FPU (Qemu)            fxam     SIM_SIM                          ... ok (  0.97s)
Test PP-DOS-GIT  FPU (Qemu)         fxtract     JIT_JIT                          ... ok (  0.75s)
Test PP-DOS-GIT  FPU (Qemu)         fxtract     KVM_KVM                          ... ok (  0.84s)
Test PP-DOS-GIT  FPU (Qemu)         fxtract  KVM_NATIVE                          ... ok (  0.79s)
Test PP-DOS-GIT  FPU (Qemu)         fxtract     SIM_SIM                          ... ok (  0.94s)
Test PP-DOS-GIT  FPU (Qemu)           fyl2x     JIT_JIT                          ... ok (  0.73s)
Test PP-DOS-GIT  FPU (Qemu)           fyl2x     KVM_KVM                          ... ok (  0.76s)
Test PP-DOS-GIT  FPU (Qemu)           fyl2x  KVM_NATIVE                          ... ok (  0.84s)
Test PP-DOS-GIT  FPU (Qemu)           fyl2x     SIM_SIM                          ... FAIL
Test PP-DOS-GIT  FPU (Qemu)         fyl2xp1     JIT_JIT                          ... ok (  0.77s)
Test PP-DOS-GIT  FPU (Qemu)         fyl2xp1     KVM_KVM                          ... ok (  0.79s)
Test PP-DOS-GIT  FPU (Qemu)         fyl2xp1  KVM_NATIVE                          ... ok (  0.80s)
Test PP-DOS-GIT  FPU (Qemu)         fyl2xp1     SIM_SIM                          ... FAIL
Test PP-DOS-GIT  FPU (Qemu) pseudo-denormal     JIT_JIT                          ... ok (  0.80s)
Test PP-DOS-GIT  FPU (Qemu) pseudo-denormal     KVM_KVM                          ... ok (  0.78s)
Test PP-DOS-GIT  FPU (Qemu) pseudo-denormal  KVM_NATIVE                          ... ok (  0.73s)
Test PP-DOS-GIT  FPU (Qemu) pseudo-denormal     SIM_SIM                          ... ok (  0.91s)
Test PP-DOS-GIT  FPU (Qemu)    snan-convert     JIT_JIT                          ... ok (  0.82s)
Test PP-DOS-GIT  FPU (Qemu)    snan-convert     KVM_KVM                          ... ok (  0.79s)
Test PP-DOS-GIT  FPU (Qemu)    snan-convert  KVM_NATIVE                          ... ok (  0.82s)
Test PP-DOS-GIT  FPU (Qemu)    snan-convert     SIM_SIM                          ... ok (  0.95s)

Actually the Github Action for that PR is running now, so there should be a new artifact.zip file with the failures to download afterwards, see https://github.com/dosemu2/dosemu2/actions/runs/5685363036.

from dosemu2.

fp sim...
Not one of those things I would enjoy fixing.
Lets see what would I need, if I wanted to:

• bug ticket
• an output of expected and obtained values

from dosemu2.

I can raise a ticket if necessary, the output/expected values are in the artefact file I mentioned above, but I can't be of much help otherwise about the tests, as they were just lifted on Bart's suggestion from the Qemu project. The sort of info you'd find in that artefact file is

FAIL: f2xm1 0x9.0950fb020f8be81p-5, expected 0xd.d65066b1a53a1e6p-6 or 0xd.d65066b1a53a1e7p-6, got 0xd.d65066b1a53a1e9p-6

Which means very little to me, but perhaps it's enough to start debugging? Anyway, don't feel pressured into doing this, I just put a little effort into wrapping the Qemu FPU tests into our test suite, but can't add them to devel as we have failures. From time to time, when I see some commit that touches anything FPU related, I rebase and rerun the tests in the hope that they perhaps now pass and I can sneak them in. I have no real world examples of any program failing on DOS due to FPU, so it's all really contrived.

from dosemu2.

Perhaps you can fill in 3 tickets.
One for rounding errors, where the mismatch
is in a least-significant digit.
Another for obviously incorrect answers,
and another for non-sim errors.

from dosemu2.

Okay I'll try to get the tickets done in the next few days, thanks.

from dosemu2.

Should now be fixed, enjoy.

Thanks! It does seem to be fixed, both testmmx.sld and dpmimmx.com work as expected now (in native DPMI mode). Considering that this had to do with the KVM mode used for 86 Mode, I assume that the state was lost/corrupted whenever the machine switched into Virtual 86 Mode, including for any DOS I/O (like what the debugger does for its interface, or the dpmimmx test when it displayed things).

from dosemu2.