Hi,
sorry for the late reply, took me a while to first built the kernel with
that options and then actually find time to play long enough.
If I did everything correctly, then I build 7.0.7 with
- CONFIG_VMAP_STACK=y
- CONFIG_KASAN=y
I did not get it to crash on that built kernel yet,
however I booted 7.0.9+deb14-amd64 once, and after playing a while got a
crash again.
I will try using the built kernel next week to see if I can get it to
crash as well.
Or do I have to look somewhere else if kasan is active?
On 18.05.26 15:43, Sean Christopherson wrote:
Odds are very good this is due to host memory corruption, and is not a bug in
KVM's MMU. We (Google) had a period of time where our kernel was triggering
stack
overflows if a networking IRQ hit at just the right/wrong time, and whenever the
overflow wandered into KVM page tables, it would result in failures like these.
I got quite familiar with the signature :-)
Not sure if it could be something else, however I at least run memtest
for ~12h without problems.
If you aren't already, can you try running with CONFIG_VMAP_STACK=y? Stack
overflow doesn't seem likely in this case since the gfn would put the SPTE in
the
middle of the page table, but it's easy enough to rule out.
The other thing to try would be to run with CONFIG_KASAN=y. That might make
your
gaming quite miserable, but if this is indeed due to a rogue write, it's the
best
shot for catching the culprit.
Regards
