On 2/24/26 00:39, Mohamed Mediouni wrote:
It's a bit of a misnomer, but didn't rename this series to not cause more
confusion... should
probably have been named more like:
whpx, target/i386/emulate: fixes for target/i386/emulate and move WHPX x86 to
it + WHPX misc fixes
Should have probably put a bit less faith in the state of target/i386/emulate
from the get-go...
In guest OSes compatibility: Win9x works now (but is not too stable...). I
probably recommend using -M kernel-irqchip=off
for that case though as it apparently raises stability (a bit). Win9x didn't
work with winhvemulate.
32-bit Haiku didn't work for me with or without this, with an invalid bit being
there in the PTEs, but 64-bit Haiku works.
On the bright side, this series should fix a lot on x86 HVF too...
Some questions/notes for mshv:
- On the model of the "whpx: i386: inject exceptions" commit, also have
injection of raised exceptions for
the MSHV backend for this all to work as expected.
- I removed the reliance on the Hyper-V GVA translate call, which is a very
slow one. If you want to add it
back instead of using the QEMU target/i386/emulate page table walker, there
probably ought to be a way to reduce
the number of calls to that...
- but emul_ops has a new mmu_gva_to_gpa call to enable this case to be
implemented
- la57 code is not exactly tested
And in missing things that are probably a better fit for a separate patch
(series) instead of this continously-growing one:
- I don't handle privileges for the page walker in target/i386/emulate
- and SMAP/SMEP for it, with complexity they might add to the picture
- and the same applies to putting the reserved bit on error_code for erroneous
PTEs
Yes, these can come later; maybe the TCG page walker could even be
shared with target/i386/emulate.
I'm queuing this thing but please take a look at my remark to patch 25
and I can squash the diff.
Paolo
