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

["Dr. David Alan Gilbert" <dave@treblig.org>]

* 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

> 
-- 
 -----Open up your eyes, open up your mind, open up your code -------   
/ Dr. David Alan Gilbert    |       Running GNU/Linux       | Happy  \ 
\        dave @ treblig.org |                               | In Hex /
 \ _________________________|_____ http://www.treblig.org   |_______/