Re: [CRM114spam]: Re: [PATCH v4 03/27] target/i386/mshv: Add x86 decoder/emu implementation

[Magnus Kulke <magnuskulke@linux.microsoft.com>]

On Tue, Sep 16, 2025 at 11:47:02PM +0000, Dr. David Alan Gilbert wrote:
> * Mohamed Mediouni (mohamed@unpredictable.fr) wrote:
> > 
> > 
> > > On 16. Sep 2025, at 19:40, Dr. David Alan Gilbert <dave@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