x86,sim: Remove special handling for KVM in the clone syscall.
authorGabe Black <gabe.black@gmail.com>
Sun, 13 Dec 2020 09:09:30 +0000 (01:09 -0800)
committerGabe Black <gabe.black@gmail.com>
Tue, 15 Dec 2020 01:36:39 +0000 (01:36 +0000)
commit09982dcbe9e2ff730bbf4fe9408b576c3f218259
tree87390670b479d4488b425014581331b95677308b
parent4db903a59f278916de85a2852224eaf660fa1b84
x86,sim: Remove special handling for KVM in the clone syscall.

When a gem5 op is triggered using a KVM MMIO exit event, the PC has
already been advanced beyond the offending instruction. Normally when
a system call or gem5 op is triggered, the PC has not advanced because
the instruction hasn't actually finished executing. This means that if
a gem5 op, and by extension a system call in SE mode, want to advance
the PC to the instruction after the gem5 op, they have to check whether
they were triggered from KVM.

To avoid having to special case these sorts of situations (currently
only in the clone system call), we can have the code which dispatches to
gem5 ops from KVM adjust the next PC so that it points to what the
current PC is. That way the PC can be advanced unconditionally, and will
point to the instruction after the one that triggered the call.

To be fully consistent, we would also need to adjust the current PC.
That would be non-trivial since we'd have to figure out where the
current instruction started, and that may not even be possible to
unambiguously determine given x86's instruction structure. Then we would
also need to restore the original PC to avoid confusing KVM.

Change-Id: I9ef90b2df8e27334dedc25c59eb45757f7220eea
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/38486
Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com>
Maintainer: Andreas Sandberg <andreas.sandberg@arm.com>
Tested-by: kokoro <noreply+kokoro@google.com>
src/cpu/kvm/base.cc
src/sim/syscall_emul.hh