On Tue, 9 Nov 2021 at 15:00, Arnabjyoti Kalita <akal...@cs.stonybrook.edu> wrote: > > Thank you very much, Peter. I have got the gist of the code flow. > Based on your explanation, I have a couple of questions to ask - > > - In cpu_restore_state(), can it happen that the host PC is incorrect > and thereby, the resultant guest PC becomes incorrect (the comments > say that this happens during TB instruction fetch)? How can this > happen? Will guest execution fail if this happens?
The comment is for a check on whether the passed in host PC is in the buffer where we generate code; it describes two cases where it might not be. In both cases, we will not attempt to update the CPU state struct, and that is the correct behaviour. Faults during instruction fetch happen not inside a TB but before starting to execute, so there is no not-yet-written-back state that needs to be handled. And faults from helper functions which didn't provide a return PC can be OK, if the generated code which calls that helper arranges to synchronize the CPU state itself. (This is the "expected" exception situation from my email from last year.) We might also get here and fail the check if there is a bug in some other part of QEMU, for instance a helper function which passed in an incorrect return address. This effect of this kind of bug would be that we would take the exception with some parts of the guest CPU state being incorrect (eg the PC would probably be pointing at the start of the TB but various effects of the instructions in the TB would have already happened). We will then continue to execute the guest but since we've messed up its state it will probably result in the guest or one of the processes within the guest crashing. > - Can it happen that a correct host PC map to an incorrect guest PC ? No (assuming no QEMU bugs, of course). -- PMM