On 27/11/2017 16:06, Peter Maydell wrote: > On 27 November 2017 at 15:53, Paolo Bonzini <pbonz...@redhat.com> wrote: >> On 27/11/2017 15:47, Peter Maydell wrote: >>> I have a patch from rth based on an idea he and I came up with: >>> we add a field to the PageDesc struct to store the thread id of >>> the thread that last touches the flags. If you come into the >>> segv handler and the page flags/last-modified-by field say "should be >>> writeable and somebody else updated it" then you mark the page as >>> "last modified by this thread" and retry the access. If the >>> flags say "should be writeable, last modified by this thread" >>> then you know the page state hasn't changed since this thread >>> last saw it as "definitely not causing segvs because of cached TBs", >>> and so that should be passed on as a guest SEGV. >> Clever, but why would si_code not work?... > Do we have a guarantee that it's absolutely never the case that > you can get a SEGV with si_code SEGV_ACCERR for an access to memory > that's mapped writeable (and conversely that we'll always get > SEGV_ACCERR for the "mapped nonwriteable" case)? If it's ever possible > then the guest will go into an infinite loop of taking segfaults that > should be delivered to the guest but which we just retry the failing > access for forever...
At least for x86, yes. For ARM, the syndrome values that trigger SEGV_ACCERR are 9-11 and 13-15, which seems sane to me but I know much less about ARM than x86. So I would say "yes except for kernel bugs". Paolo
