diff options
author | Liran Alon <liran.alon@oracle.com> | 2019-06-19 19:21:34 +0300 |
---|---|---|
committer | Paolo Bonzini <pbonzini@redhat.com> | 2019-06-21 02:29:39 +0200 |
commit | bceeeef9e7544057659118688243260c390eceb9 (patch) | |
tree | 481e6756a57bc09f3a0647426833694ebac60293 /qemu-doc.texi | |
parent | 37936ac70f6c20aec6f537349eb797fb98f9a99d (diff) | |
download | qemu-bceeeef9e7544057659118688243260c390eceb9.zip |
target/i386: kvm: Re-inject #DB to guest with updated DR6
If userspace (QEMU) debug guest, when #DB is raised in guest and
intercepted by KVM, KVM forwards information on #DB to userspace
instead of injecting #DB to guest.
While doing so, KVM don't update vCPU DR6 but instead report the #DB DR6
value to userspace for further handling.
See KVM's handle_exception() DB_VECTOR handler.
QEMU handler for this case is kvm_handle_debug(). This handler basically
checks if #DB is related to one of user set hardware breakpoints and if
not, it re-inject #DB into guest.
The re-injection is done by setting env->exception_injected to #DB which
will later be passed as events.exception.nr to KVM_SET_VCPU_EVENTS ioctl
by kvm_put_vcpu_events().
However, in case userspace re-injects #DB, KVM expects userspace to set
vCPU DR6 as reported to userspace when #DB was intercepted! Otherwise,
KVM_REQ_EVENT handler will inject #DB with wrong DR6 to guest.
Fix this issue by updating vCPU DR6 appropriately when re-inject #DB to
guest.
Reviewed-by: Nikita Leshenko <nikita.leshchenko@oracle.com>
Reviewed-by: Krish Sadhukhan <krish.sadhukhan@oracle.com>
Signed-off-by: Liran Alon <liran.alon@oracle.com>
Message-Id: <20190619162140.133674-5-liran.alon@oracle.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Diffstat (limited to 'qemu-doc.texi')
0 files changed, 0 insertions, 0 deletions