KVM: Rudimentary support for VCPI

[bartoldeman]

Implement basic VCPI support with limitations.
The limitations are:
$_dpmi = (0)
$_ems = (0)

• don't use FDPP
• use external XMS provider (HIMEM/FDXMS)

VCPI clients allocate memory from XMS only, so EMS needs to report 0 memory, and XMS needs to map identical "physical" memory starting at 0x110000, which would normally be taken by DPMI memory.

The page table maps LOW+HMA as usual, then a page at 0x110000 to monitor code implementing a monitor->VCPI client jump and a VCPI client -> VM86 jump. A page at 0x111000 contains the saved monitor GDTR/IDTR/CR3 values and a temporary stack, with hiword(esp)=0, for the client to use. The monitor code is much like Jemm's.

When KVM interrupts the VCPI client through a signal, DOSEMU does its regular things, but CANNOT modify any registers, as the client registers stay in the VM. pic_run() will see VIF is not set, so won't modify, and the kvm.c code needs to use KVM_INTERRUPT if pic_pending().
The only other place that has been adapted for a callback into vm86 is leavedos().

VGAEMU memory is unprotected for now, so updates aren't reliable, and VGA planar modes don't work.

DOOM is playable but a bit slow due to frequent VGA I/O port accesses which would normally go via instremu. Duke Nukem 3D runs but with choppy sound and incomplete screen updates.

[stsp]

VCPI clients allocate memory from XMS only, so EMS needs to report 0 memory, and XMS needs to
map identical "physical" memory starting at 0x110000, which would normally be taken by DPMI memory.

I reverted that optimization in #1881.
Please let me know if this is what you
are looking for - that should allow vpci
to work with internal XMS.

Other than that - quite interesting, but
could you please describe exactly what
does this give us? win95?
Also you likely want to ruin the arm port,
don't you? :) Or maybe you want to move
to tcg, allowing the arm port to provide
vcpi too?

[stsp]

Have you considered the use of
the KVM_CAP_SYNC_REGS, as
in #1408 ?
Unless I am missing the actual
problem you are facing, with
SYNC_REGS the aforementioned
limitations will go away because
you will always have the right
registers at hands. Monitor then
doesn't have to save/restore them.

[stsp]

VGAEMU memory is unprotected for now, so updates aren't reliable, and VGA planar modes don't work.

We still have the vgacpy branch in #1099
Hmm, looks like we have many solutions
around, waiting for a problem. :) And
here it is, a problem.

[stsp]

The page table maps LOW+HMA as usual, then a page at 0x110000 to monitor code

Can you put it somewhere upwards,
into the "main_pool"?

[stsp]

By dirtying all pages. Can be improved using KVM_GET_DIRTY_LOG.

As in #198 ?

[bartoldeman]

At the moment this is mostly a playground to see what is possible, with a VCPI client having full control over the VM, and to test some ideas, perhaps find some bugs, it also allows quick checking how DPMI provider X behaves vs. dosemu2's DPMI implementation. Then some of the ideas could go into devel before this would be merged.

This is for the moment a KVM only thing, nothing against Arm, just a bonus when KVM is there for now.

Sure Windows 95 and various games that need VCPI or flat real mode would be a bonus for sure.

The page table maps LOW+HMA as usual, then a page at 0x110000 to monitor code

Can you put it somewhere upwards,
into the "main_pool"?

How do you mean, moving the code and data page from the monitor to two pages allocated from the main pool?
I mean the whole monitor can be allocated from the main pool if we like now. Then we'd only have a single mmap for DOS addressable space.

VCPI spec says they must be mapped into the first 4MB (linear), could be in low space (e.g. I could put the VCPI<->VM86 switch code in bios.S), or mapped from somewhere high (which is what I'm doing now, monitor is high)

Note that before VCPI, KVM always identity maps, from guest virtual space to guest physical space. This keeps it consistent with native DPMI. But with VCPI the client has control over page tables so we only have control over physical space except (collaboratively!) for the first 1MB + 64k + up to 3 MB of virtual address space. That's why DPMI had to be disabled in the config, so that extmem is at physical (not linear) 0x110000.

As in #198 ?
yes

[stsp]

That's why DPMI had to be disabled in the config, so that extmem is at physical (not linear) 0x110000.

This part I don't understand.
dpmi_base is far above ext_mem.
They are quite unrelated.
With the reverts I did in a nearby
branch, ext_mem is going to be
mapped to the physical 0x110000
under KVM by the means of EPT.
So what is the problem?

[stsp]

ext_mem is aliased to some high space in
main_pool, and to 0x110000. Under KVM,
both these windows actually represent the
physical addresses. And the linear addresses
too, if we set up the identity page tables.
But I don't see any connection with dpmi,
could you please clarify?

[bartoldeman]

oh I may be slightly out of date, as I see now that dpmi_base's default was moved from 8MB to 32MB. Which leaves max 31MB for extmem now.

Still for HX, 0x400000 (at 4MB linear) needs to be available for DPMI right, see #612?
So there's a conflict with extmem (if it uses more than 3MB, and mapped at 0x110000 linear) or is this handled somehow?

[stsp]

Yeah, that's right, and that part
I forgot to revert. :) Added the missing
reverts now.
Also I am not sure ext_mem is
actually mapped where it should,
even with reverts, because
MAPPING_INIT_LOWRAM alias
still seems to be done w/o ext_mem
size in low_mem_init(). But that's
trivial to fix.
So I suppose perhaps you don't
need to disable dpmi fully, just break
HX when vcpi switched on?

[stsp]

I added the patch that is supposed
to map it to kvm's phys addr now for
real. :)

[stsp]

So there's a conflict with extmem (if it uses more than 3MB, and mapped at 0x110000 linear) or is this handled
somehow?

In devel this is handled by mapping
ext_mem to higher addresses. Which
is the problem for vcpi, as under kvm
that "higher address" is a phys address.
In xms_rv branch this is handled by
lowering the ext_mem size...
But in a guest we don't need to map
ext_mem to any linear address. So perhaps
the better fix would be to leave things
as they are in devel and invent non-identity
maps for kvm? But that looks too tricky.

[stsp]

Well I guess the easiest solution for
now would be for you to just integrate
the xms_rv branch into yours, w/o pushing
it to devel. This will allow you to play with
3Mb of ext_mem, or increase it by the
cost of breaking HX, and later come up
with some other solution.

[stsp]

Hmm, perhaps I've found the simple
solution:
57c667b
Why not to just use dpmi_rsv_low
as ext_mem?

[stsp]

Except that then we shouldn't
write-protect reserved area, so
1e62ebf

[stsp]

xms_rv built and I think its quite
simple to apply to devel. Would
you like to check that it actually
helps vcpi?

[stsp]

I merged identity mapping for
ext_mem, so hope disabling DPMI
will not be needed for VCPI.

[stsp]

With this patch:

--- a/src/base/emu-i386/kvm.c
+++ b/src/base/emu-i386/kvm.c
@@ -1050,7 +1050,9 @@ static unsigned int kvm_run(void)
   }
 
   while (!exit_reason) {
+warn("enter %c\n", lowmem_base[(0xffff<<4)+0x10]);
     int ret = ioctl(vcpufd, KVM_RUN, NULL);
+warn("exit %c\n", lowmem_base[(0xffff<<4)+0x10]);
     int errn = errno;
 
     /* KVM should only exit for four reasons:

I eventually see in the log:

Warning: enter M
Warning: exit .

So the game corrupts HMA and freedos
is any "better" only because it doesn't have
the proper HMA manager.

[stsp]

CS is 0x2a8 on enter and mcbs are:

ADDR(LOW) PARAS  OWNER
0263:0000 0x0013 [CRUSADER - Environment]
0277:0000 0x0770 [CRUSADER]
09e8:0000 0x0100 [9ced - Data]

So its a crusader's CS.

[bartoldeman]

ok, this could be an A20-line issue then. I think perhaps some place needs to force a20 on to make this work.

[bartoldeman]

The dosbox instructions have some loadfix stuff in them, so that may be it!

[stsp]

OK I see the bug actually... or
a part of it. Give me a bit of time.

[stsp]

Should now be fixed.
The problem is that our debugger
queried the HMA start, and fdpp is
too permissive and just enables HMA
if it wasn't enabled already.
Its undesirable when the program
wants to use HMA on its own as
crusader does.
So I added an extra check to the debugger.
Could also restrict fdpp, but oh well.

Note that with DOS=HIGH the problem
will re-appear. But who cares if its not
a default. :)

[bartoldeman]

Yes it works now, thanks, just with noisy error messages when internal XMS is used.
Also the DOSEMU2 window title bar now changed CRUSADER to some strange characters, but will try to narrow down when that started. It's all consistent between FDPP and fdkernel though now!