On Thu, Nov 06, 2025 at 11:23:32AM +0900, Akihiko Odaki wrote: > Generally speaking, we will not necessarily "always" get an issue report > when things went wrong with memory management. A bug in memory management > may not cause an immediate crash but corrupt the memory state which you will > find only later. The end result of memory corruption may look random and > result in a hard-to-debug issue report. A user may not even bother writing > an issue report at all; this is especially true for this kind of corner > cases that rarely happen. > > There should have been no such a hazard of memory corruption if the code did > exactly what the documentation said in the first place. The consistency of > the code and the documentation is essential, especially for this kind of > complex and fundamental code.
Do you have encountered such case before? I wasn't expecting that, because what you were saying looks more like what Linux kernel would have a bug in mm. QEMU is still special as it has the default unassigned MR trapping everything by default, meanwhile normally what is moving is MMIO / alias regions rather than real ramblocks. It means when things go wrong we have much higher chance to trap them properly. I also confess though that I'm pretty conservative on fixing things with hypothetical issues. In general, I prefer fixing things with explicit problems, so we know how to measure and justify a fix (depending on how aggressive the fix is and how much maintanence burden it will bring to QEMU). Without a real problem, it's harder to quantify that even if such evaluation will also normally be subjective too. Thanks, -- Peter Xu
