On Tue, Sep 16, 2025 at 11:47:02PM +0000, Dr. David Alan Gilbert wrote: > * Mohamed Mediouni (moha...@unpredictable.fr) wrote: > > > > > > > On 16. Sep 2025, at 19:40, Dr. David Alan Gilbert <d...@treblig.org> > > > wrote: > > > > > > For example 'x86_is_real' is declared in target/i386/emulate/x86.h > > > and defined in target/i386/hvf/x86.c (hmm that's a bit weird). > > > So it's probably best to check if what you want already exists, > > > move it into target/i386 somewhere I guess, and everyone shares it. > > > Currently there isn’t a backend-agnostic interface for this. > > It was part of the import of HVF support to qemu from downstream. > > Hmm. > > > Notably means that the emulate infrastructure isn’t usable by multiple > > backends in the same build. It might be possible to get away without that > > however as HVF is macOS specific, MSHV is Linux-specific and WHPX > > (which is currently using winhvemulator instead of this) is > > Windows-specific... > > It does scare me a bit having 2 different functions with the same name like > that; > but hmm OK... > > But - x86_is_real() is identical in these cases - the x86_is_protected() is > the > implementation dependent bit. > The only bit that seems different is the reading of the register, eg. CR0, so > there > could be a: > > x86_read_CR0(CPUState *cpu) > and the x86_is_real and x86_is_paging_mode all be shared (as inline's ???). > > But this does all get messy - I mean, even if MSHV is Linux specific, and HVF > is macos specific; it's a shame that the logic behind x86_is_* is open coded > in all of tcg, kvm and copied twice in hvf and mshv. > > (I don't understand the structure as to why some stuff needs backend specific > reads and some are in env). > > Dave
Hey Dave, in preperation for the MSHV patches Wei Liu did rework the HVF x86 emulator code and abstracted it into target/i386/emulate, so we could use prior art as much as possible. Since HVF had to perform similar userland decoding/emulation of instruction on MMIO exits that was a good fit. However, the requirements are not exactly the same. Thus, in the current approach there is some duplication, like `x86_is_real()` (which is sort of trivial and arguably could indeed be inlined), but e.g. `x86_is_paging_mode()` would have different implementations per accelerator target. best, magnus
