On Mon, 2021-06-07 at 18:15 +0000, Philipp Ammann wrote:
> Am 07.06.21 um 16:27 schrieb Simon Becherer:
> > I tried minport vbe driver
> > (https://web.archive.org/web/20191129030225/https://bearwindows.zcm.com.au/vbe9x.htm#2)
> > with cirrus/vga/vmga card
> > and cirrus driver with cirrus card - but without sucess.
> > Both 95 and 98 hangs during shutting down :(
> >
> > Any hints?
>
> Cirrus should work fine with the stock drivers included in Windows.
> Personally I'm using vmware with the official VMware driver. You can
> extract the driver for Win9x from preWin2k.iso shipped with VMware.
>
> Bonus: set vmport=on (may be default) an install the vmmouse driver from
> said ISO, and try vmxnet3 if you need networking.
>
I have a win98 VM with qemu/kvm and I play with it once a while,
because win98 was my first and last windows I used as a primary OS before
I discovered and switched to Linux.
Many will disagree with me but I still think that win98 was the last windows
version
that didn't suck at least from user perspective.
Even despite the crashes/etc.
Here are few tips I know of running win98 on KVM/Qemu:
* Cirrus works (and it was my GPU back when I used win98 on real hardware),
and is the most accurate, but is *slow* and very resolution limited.
(I can't understand how I could use 800x600 for so many years, and then I
remember I finally updated to 1024x768,
that was awesome and then when I switched to 1280x1024, it felt like I have
infinite space.
These days I use 41 inch 4K monitor for my work, and I'll say it is about the
amount of space I would like to have.
For the win98 VM I use a standard VGA and found a universal VGA driver for it.
I think I use the one from https://bearwindows.zcm.com.au/vbe9x.htm.
The downsides of VGA driver I think are that if you attempt to open DOS
prompt,
the screen fills with garbage, I think that DOS gets direct access to VGA
registers or something,
and messes something up. It does work on cirrus though.
* That hang on shutdown I have seen too. Seems if you open a full screen DOS
window once,
then it works (full screen window doesn't garbage the screen).
I setup a dummy PIF file in the autostart folder that does that for me.
It also smells like some bug in Qemu VGA implementaiton.
* KVM also used to make windows hang on boot when its logo is shown, but it got
fixed some kernels ago,
so logo=0 in msdos.sys is no longer needed to boot it.
* Mouse. If you use win98 SE, then you have support for USB, and qemu's tablet
works and works very well.
You do need to manually install driver for PnP BIOS though, but I guess you
already did that.
* Storage: I enabled DMA on IDE controller, seemed to be disabled by default,
and helped a lot with speed.
* Sound: the SB16 works, but causes the mouse to freeze while sound playing. It
is also very inefficient,
as it uses PIO.
I use AC97 driver for which I found very old win95 drivers which seems to
work (win98 drivers crash)
It might be this driver: https://archive.org/details/ac97-win95
* Usage on any AMD processor (or at least Ryzen):
Sadly win98 contains a TLB flush bug, such as it doesn't flush TLB after it
modifies a page table entry,
with invtlb.
Ryzen's TLB is more speculative that Intel's and it just makes the guest show
error messages, all the time,
and be mostly unusable, while in Intel's cpus for which it was developed, it
seems to "work"
What partially helps is to disable swap file in the guest but doesn't fully
eliminate it of course.
What is even funnier is that when you use KVM's shadow MMU (use kvm_amd
kernel module with npt=0), the bug
is still present because well KVM's shadow MMU also speculates.
I do have a patch which I use locally sometimes to make it strict and then
win98 works relatively fine.
(I still see some crashes and hangs once in a while, but they might be even
because the OS itself isn't that stable).
To use the attached patch you need to add 'strict_mmu=1' option to the kvm
module (note, not kvm_amd), and load kvm_amd module
with npt=0.
Of course the sad part is that in this configuration you can't really run any
other VMs, as they are just too slow,
so I have to reload kvm kernel modules when I like to play with win98 VM.
Also on Ryzen 1, there was something related to VME extension, but I think
that AMD fixed it.
No luck so far with VFIO. I have a very old nvidia card (7600GS I think) and
once I was able to pass it through to winxp VM on KVM,
and recently I was able to make it at least show something on screen with a
eGPU box, but alas I think that the card died.
I don't think that this card supports win98 though. Since I still have that
eGPU box, I might as well one day buy an older card
and try to pass it through.
And last thing, something curious. Every time I see win98 desktop in a window,
I think that sides of the window are curved inside, like a kind of pincushion
distortion.
The only explanation I can have is that my brain still applies geometric
correction to flatten the CRT image.
OK, enough nostalgia from me!
Best regards,
Maxim Levitsky
From 6f6f0a51cb73aa25b3c5777796ec4e23e8d64dd3 Mon Sep 17 00:00:00 2001
From: Maxim Levitsky <mlevi...@redhat.com>
Date: Sat, 13 Feb 2021 18:04:04 +0200
Subject: [PATCH 01/16] KVM: x86: mmu: add strict mmu mode
Signed-off-by: Maxim Levitsky <mlevi...@redhat.com>
---
arch/x86/kvm/mmu/mmu.c | 9 ++++++++-
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/arch/x86/kvm/mmu/mmu.c b/arch/x86/kvm/mmu/mmu.c
index 112b221e1e6a9d..a1130daa5a9356 100644
--- a/arch/x86/kvm/mmu/mmu.c
+++ b/arch/x86/kvm/mmu/mmu.c
@@ -91,6 +91,10 @@ __MODULE_PARM_TYPE(nx_huge_pages_recovery_period_ms, "uint");
static bool __read_mostly force_flush_and_sync_on_reuse;
module_param_named(flush_on_reuse, force_flush_and_sync_on_reuse, bool, 0644);
+
+bool strict_mmu;
+module_param(strict_mmu, bool, 0644);
+
/*
* When setting this variable to true it enables Two-Dimensional-Paging
* where the hardware walks 2 page tables:
@@ -2716,7 +2720,7 @@ static int mmu_set_spte(struct kvm_vcpu *vcpu, struct kvm_memory_slot *slot,
}
wrprot = make_spte(vcpu, sp, slot, pte_access, gfn, pfn, *sptep, prefetch,
- true, host_writable, &spte);
+ !strict_mmu, host_writable, &spte);
if (*sptep == spte) {
ret = RET_PF_SPURIOUS;
@@ -5125,6 +5129,9 @@ static u64 mmu_pte_write_fetch_gpte(struct kvm_vcpu *vcpu, gpa_t *gpa,
*/
static bool detect_write_flooding(struct kvm_mmu_page *sp)
{
+ /* In strict mmu case we don't unsync pages ever */
+ if (strict_mmu)
+ return true;
/*
* Skip write-flooding detected for the sp whose level is 1, because
* it can become unsync, then the guest page is not write-protected.
--
2.26.3
