Some guest OSes trigger them way too often.

Signed-off-by: Mohamed Mediouni <mohamed@unpredictable.fr>
---
 meson.build                      | 1 +
 target/i386/emulate/trace-events | 2 ++
 target/i386/emulate/trace.h      | 2 ++
 target/i386/emulate/x86_mmu.c    | 5 +++--
 4 files changed, 8 insertions(+), 2 deletions(-)
 create mode 100644 target/i386/emulate/trace-events
 create mode 100644 target/i386/emulate/trace.h

diff --git a/meson.build b/meson.build
index e6f17dd5f7..5a2e7a491d 100644
--- a/meson.build
+++ b/meson.build
@@ -3691,6 +3691,7 @@ if have_system or have_user
     'target/arm/hvf',
     'target/hppa',
     'target/i386',
+    'target/i386/emulate',
     'target/i386/kvm',
     'target/loongarch',
     'target/mips/tcg',
diff --git a/target/i386/emulate/trace-events b/target/i386/emulate/trace-events
new file mode 100644
index 0000000000..e353969661
--- /dev/null
+++ b/target/i386/emulate/trace-events
@@ -0,0 +1,2 @@
+x86_unhandled_memory_read(uint64_t gpa, int bytes) "read from unmapped mmio region gpa=0x%" PRIx64 " size=%i"
+x86_unhandled_memory_write(uint64_t gpa, int bytes) "write to unmapped mmio region gpa=0x%" PRIx64 " size=%i"
diff --git a/target/i386/emulate/trace.h b/target/i386/emulate/trace.h
new file mode 100644
index 0000000000..8c2317b152
--- /dev/null
+++ b/target/i386/emulate/trace.h
@@ -0,0 +1,2 @@
+/* SPDX-License-Identifier: LGPL-2.1-or-later */
+#include "trace/trace-target_i386_emulate.h"
diff --git a/target/i386/emulate/x86_mmu.c b/target/i386/emulate/x86_mmu.c
index c69ae96acb..e5f4dd8a65 100644
--- a/target/i386/emulate/x86_mmu.c
+++ b/target/i386/emulate/x86_mmu.c
@@ -25,6 +25,7 @@
 #include "emulate/x86.h"
 #include "emulate/x86_emu.h"
 #include "emulate/x86_mmu.h"
+#include "trace.h"
 
 #define pte_present(pte) (pte & PT_PRESENT)
 #define pte_write_access(pte) (pte & PT_WRITE)
@@ -287,7 +288,7 @@ static MMUTranslateResult x86_write_mem_ex(CPUState *cpu, void *data, target_ulo
                             MEMTXATTRS_UNSPECIFIED, data, copy);
 
         if (mem_tx_res == MEMTX_DECODE_ERROR) {
-            warn_report("write to unmapped mmio region gpa=0x%" PRIx64 " size=%i", gpa, bytes);
+            trace_x86_unhandled_memory_write(gpa, bytes);
             return MMU_TRANSLATE_GPA_UNMAPPED;
         } else if (mem_tx_res == MEMTX_ACCESS_ERROR) {
             return MMU_TRANSLATE_GPA_NO_WRITE_ACCESS;
@@ -339,7 +340,7 @@ static MMUTranslateResult x86_read_mem_ex(CPUState *cpu, void *data, target_ulon
                            data, copy);
 
         if (mem_tx_res == MEMTX_DECODE_ERROR) {
-            warn_report("read from unmapped mmio region gpa=0x%" PRIx64 " size=%i", gpa, bytes);
+            trace_x86_unhandled_memory_read(gpa, bytes);
             return MMU_TRANSLATE_GPA_UNMAPPED;
         } else if (mem_tx_res == MEMTX_ACCESS_ERROR) {
             return MMU_TRANSLATE_GPA_NO_READ_ACCESS;
-- 
2.50.1 (Apple Git-155)

On 3/26/26 11:36 AM, Mohamed Mediouni wrote:
> Some guest OSes trigger them way too often.
> 
> Signed-off-by: Mohamed Mediouni <mohamed@unpredictable.fr>
> ---
>   meson.build                      | 1 +
>   target/i386/emulate/trace-events | 2 ++
>   target/i386/emulate/trace.h      | 2 ++
>   target/i386/emulate/x86_mmu.c    | 5 +++--
>   4 files changed, 8 insertions(+), 2 deletions(-)
>   create mode 100644 target/i386/emulate/trace-events
>   create mode 100644 target/i386/emulate/trace.h
> 

To justify the change, it could help if you could add a better commit 
description explaining:
- which OSes are concerned (older windows?)
- analysis why they do such a thing (at least see some QEMU backtraces 
when this happen).

 From what I see, this code is triggered either from hvf, or when 
running an ins instruction, so you could explain which scenario you're 
covering.

Finally, this change is quite unrelated to whpx, which can be a bit 
confusing giving the initial intent of your series.
In case it might help you, git update-refs [1] is a great solution for 
working with stacked branches/series, without the pain of having to deal 
with multiple branches.

[1] https://dev.to/onepoint/git-update-refs-in-a-nutshell-574c

Regards,
Pierrick

> On 26. Mar 2026, at 19:46, Pierrick Bouvier <pierrick.bouvier@linaro.org> wrote:
> 
> On 3/26/26 11:36 AM, Mohamed Mediouni wrote:
>> Some guest OSes trigger them way too often.
>> Signed-off-by: Mohamed Mediouni <mohamed@unpredictable.fr>
>> ---
>>  meson.build                      | 1 +
>>  target/i386/emulate/trace-events | 2 ++
>>  target/i386/emulate/trace.h      | 2 ++
>>  target/i386/emulate/x86_mmu.c    | 5 +++--
>>  4 files changed, 8 insertions(+), 2 deletions(-)
>>  create mode 100644 target/i386/emulate/trace-events
>>  create mode 100644 target/i386/emulate/trace.h
> 
> To justify the change, it could help if you could add a better commit description explaining:
> - which OSes are concerned (older windows?)
> - analysis why they do such a thing (at least see some QEMU backtraces when this happen).
Hello,

Neither Windows or Linux are concerned by this one, but the 
ReactOS install ISO - among some other more rare OSes - trigger it.

Intriguingly, the ReactOS live ISO doesn’t trigger it.

> 
> From what I see, this code is triggered either from hvf, or when running an ins instruction, so you could explain which scenario you're covering.

WHPX has been moved to target/i386/emulate for 11.0, it’s no
longer using winhvemulation.

And that means that it’s a load bearing path through which
load/stores on every MMIO access by an emulated instruction
goes through. And even reading part of the instruction itself
if Hyper-V doesn’t give a complete one.

Thanks,
-Mohamed

On 3/26/26 11:53 AM, Mohamed Mediouni wrote:
> 
> 
>> On 26. Mar 2026, at 19:46, Pierrick Bouvier <pierrick.bouvier@linaro.org> wrote:
>>
>> On 3/26/26 11:36 AM, Mohamed Mediouni wrote:
>>> Some guest OSes trigger them way too often.
>>> Signed-off-by: Mohamed Mediouni <mohamed@unpredictable.fr>
>>> ---
>>>   meson.build                      | 1 +
>>>   target/i386/emulate/trace-events | 2 ++
>>>   target/i386/emulate/trace.h      | 2 ++
>>>   target/i386/emulate/x86_mmu.c    | 5 +++--
>>>   4 files changed, 8 insertions(+), 2 deletions(-)
>>>   create mode 100644 target/i386/emulate/trace-events
>>>   create mode 100644 target/i386/emulate/trace.h
>>
>> To justify the change, it could help if you could add a better commit description explaining:
>> - which OSes are concerned (older windows?)
>> - analysis why they do such a thing (at least see some QEMU backtraces when this happen).
> Hello,
> 
> Neither Windows or Linux are concerned by this one, but the
> ReactOS install ISO - among some other more rare OSes - trigger it.
> 
> Intriguingly, the ReactOS live ISO doesn’t trigger it.
>

Might be a good idea to report that to them, as it seems like something 
wrong is going on, which was the point of having this (loud) warning in 
the first place.

>>
>>  From what I see, this code is triggered either from hvf, or when running an ins instruction, so you could explain which scenario you're covering.
> 
> WHPX has been moved to target/i386/emulate for 11.0, it’s no
> longer using winhvemulation.
> 
> And that means that it’s a load bearing path through which
> load/stores on every MMIO access by an emulated instruction
> goes through. And even reading part of the instruction itself
> if Hyper-V doesn’t give a complete one.
>

I see.

In this case, maybe a better compromise than using custom trace events 
would be to make it visible when using -d guest_errors.
The problem is that custom trace events are hidden for users, and except 
if you know it exists, it's impossible to guess it's there.

On the opposite, -d guest_errors can be discovered by someone curious 
with `qemu-system-x86_64 -d help`, and it's the same flag for all 
architectures.

> Thanks,
> -Mohamed
> 

Regards,
Pierrick