Re: Page Fault Handling in TCG mode

[Peter Maydell]

On Tue, 9 Nov 2021 at 05:44, Arnabjyoti Kalita
<akalita@cs.stonybrook.edu> wrote:
> I am trying to understand how page faults happen when a guest is
> executing in TCG mode. Specifically, how does TCG determine at which
> instruction pointer did page fault happen? Which functions in the TCG
> code flow get called when it detects that memory is not present in the
> page table?

Very rough sketch; I'm going to assume system emulation mode.
I'm also going to assume current head-of-git, not 5.0.1, because
if you're interested in QEMU internals you should be working
with the current QEMU, not one that's two years old. (The
general principles haven't changed, but some of the function
names might have.)

First, remember the description at the end of this email
https://lists.nongnu.org/archive/html/qemu-discuss/2020-08/msg00037.html
about different ways of handling guest exceptions? Page faults
are in the 'unexpected' exception category.

In system emulation mode, a guest access which might cause a
page fault will always go through the slow-path for guest
load/store emulation, which is to say that it calls out from
generated code into QEMU's C helper functions. The C helper
function will notice that there's nothing in the QEMU TLB
for this guest address, and call the guest-architecture
tlb_fill function to try to remedy this (eg x86_cpu_tlb_fill()).
The helper functions pass in the host address in the TCG generated
code that we've just come from -- we'll need that later.
The tlb_fill function will do a guest page table walk. If the
page table walk succeeds then we fill in the QEMU TLB entry and
continue with emulating the load/store. If the page table walk
fails, then we need to deliver a page fault. We do that by:
 * setting up some internal state to say what the exception was
 * calling cpu_restore_state() to fix up the guest CPU state
   to match the guest PC corresponding to the host PC
   in the 'return address' we've been carrying around
 * calling cpu_loop_exit() to longjump back out to the top
   level emulation loop, which then will notice there's a
   pending exception and call the guest-architecture hook to
   take the exception
(In the x86 code that's done via a collection of functions
starting with raise_exception_err_ra() -- you can walk
through them and find exactly where the things above are done.)

-- PMM