ReactOS's install ISO does a bunch of 4-byte accesses
to 0xffdff124. This doesn't happen for the boot ISO.

It looks to be an access relative to the Windows KPCR
which is at 0xffdff000 but mistakenly done prior to
paging being on...

As this logging is redundant with -d invalid_mem,
remove it.

https://geoffchappell.com/studies/windows/km/ntoskrnl/inc/ntos/i386_x/kpcr.htm

Signed-off-by: Mohamed Mediouni <mohamed@unpredictable.fr>
---
 target/i386/emulate/x86_mmu.c | 3 ---
 1 file changed, 3 deletions(-)

diff --git a/target/i386/emulate/x86_mmu.c b/target/i386/emulate/x86_mmu.c
index c69ae96acb..007de582de 100644
--- a/target/i386/emulate/x86_mmu.c
+++ b/target/i386/emulate/x86_mmu.c
@@ -21,7 +21,6 @@
 #include "cpu.h"
 #include "system/address-spaces.h"
 #include "system/memory.h"
-#include "qemu/error-report.h"
 #include "emulate/x86.h"
 #include "emulate/x86_emu.h"
 #include "emulate/x86_mmu.h"
@@ -287,7 +286,6 @@ 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);
             return MMU_TRANSLATE_GPA_UNMAPPED;
         } else if (mem_tx_res == MEMTX_ACCESS_ERROR) {
             return MMU_TRANSLATE_GPA_NO_WRITE_ACCESS;
@@ -339,7 +337,6 @@ 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);
             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 4:31 PM, Mohamed Mediouni wrote:
> ReactOS's install ISO does a bunch of 4-byte accesses
> to 0xffdff124. This doesn't happen for the boot ISO.
> 
> It looks to be an access relative to the Windows KPCR
> which is at 0xffdff000 but mistakenly done prior to
> paging being on...
> 
> As this logging is redundant with -d invalid_mem,
> remove it.
>

It's not obvious why it's redundant, I don't see another mmio write path 
from exec_movs_single.

> https://geoffchappell.com/studies/windows/km/ntoskrnl/inc/ntos/i386_x/kpcr.htm
> 
> Signed-off-by: Mohamed Mediouni <mohamed@unpredictable.fr>
> ---
>   target/i386/emulate/x86_mmu.c | 3 ---
>   1 file changed, 3 deletions(-)
>

> On 27. Mar 2026, at 01:38, Pierrick Bouvier <pierrick.bouvier@linaro.org> wrote:
> 
> On 3/26/26 4:31 PM, Mohamed Mediouni wrote:
>> ReactOS's install ISO does a bunch of 4-byte accesses
>> to 0xffdff124. This doesn't happen for the boot ISO.
>> It looks to be an access relative to the Windows KPCR
>> which is at 0xffdff000 but mistakenly done prior to
>> paging being on...
>> As this logging is redundant with -d invalid_mem,
>> remove it.
>> 
> 
> It's not obvious why it's redundant, I don't see another mmio write path from exec_movs_single.

Hello,

It’s a bit long but it gets there :)

For example on the read path:

exec_movs_single -> read_val_from_mem -> read_mmio -> x86_read_mem

x86_read_mem_ex -> address_space_read -> flatview_read_continue or address_space_read_full

address_space_read_full -> flatview_read -> flatview_read_continue -> flatview_read_continue_step -> memory_region_dispatch_read -> memory_region_access_valid

and memory_region_access_valid raises that error message with -d invalid_mem

And on the write side it’s fairly similar, with it ending on memory_region_access_valid
at the end.

It’s a bit of a labyrinth though.

> 
>> https://geoffchappell.com/studies/windows/km/ntoskrnl/inc/ntos/i386_x/kpcr.htm
>> Signed-off-by: Mohamed Mediouni <mohamed@unpredictable.fr>
>> ---
>>  target/i386/emulate/x86_mmu.c | 3 ---
>>  1 file changed, 3 deletions(-)

On 3/26/26 5:48 PM, Mohamed Mediouni wrote:
> 
> 
>> On 27. Mar 2026, at 01:38, Pierrick Bouvier <pierrick.bouvier@linaro.org> wrote:
>>
>> On 3/26/26 4:31 PM, Mohamed Mediouni wrote:
>>> ReactOS's install ISO does a bunch of 4-byte accesses
>>> to 0xffdff124. This doesn't happen for the boot ISO.
>>> It looks to be an access relative to the Windows KPCR
>>> which is at 0xffdff000 but mistakenly done prior to
>>> paging being on...
>>> As this logging is redundant with -d invalid_mem,
>>> remove it.
>>>
>>
>> It's not obvious why it's redundant, I don't see another mmio write path from exec_movs_single.
> 
> Hello,
> 
> It’s a bit long but it gets there :)
> 
> For example on the read path:
> 
> exec_movs_single -> read_val_from_mem -> read_mmio -> x86_read_mem
> 
> x86_read_mem_ex -> address_space_read -> flatview_read_continue or address_space_read_full
> 
> address_space_read_full -> flatview_read -> flatview_read_continue -> flatview_read_continue_step -> memory_region_dispatch_read -> memory_region_access_valid
> 
> and memory_region_access_valid raises that error message with -d invalid_mem
>

I didn't try -d invalid_mem on x86_64-softmmu, but on aarch64-softmmu, 
it can be more noisy than guest_errors.
In this case, your analysis proved the message was a proper guest_error 
in ReactOS, so I think it's worth keeping the warning but in a different 
category (guest_errors).

> And on the write side it’s fairly similar, with it ending on memory_region_access_valid
> at the end.
> 
> It’s a bit of a labyrinth though.
> 
>>
>>> https://geoffchappell.com/studies/windows/km/ntoskrnl/inc/ntos/i386_x/kpcr.htm
>>> Signed-off-by: Mohamed Mediouni <mohamed@unpredictable.fr>
>>> ---
>>>   target/i386/emulate/x86_mmu.c | 3 ---
>>>   1 file changed, 3 deletions(-)
> 

Regards,
Pierrick