On 15/10/18 11:50, Razvan Cojocaru wrote: > On 10/15/18 1:36 PM, Andrew Cooper wrote: >> Reusing debugreg[5] for the PV emulated IO breakpoint information is >> confusing >> to read. Instead, introduce a dr7_emul field in pv_vcpu for the pupose. >> >> With the PV emulation out of the way, debugreg[4,5] are entirely unused and >> don't need to be stored. >> >> Rename debugreg[0..3] to dr[0..3] to reduce code volume, but keep them as an >> array because their behaviour is identical and this helps simplfy some of the >> PV handling. Introduce dr6 and dr7 fields to replace debugreg[6,7] which >> removes the storage for debugreg[4,5]. >> >> In arch_get_info_guest(), handle the merging of emulated dr7 state alongside >> all other dr handling, rather than much later. >> >> Signed-off-by: Andrew Cooper <[email protected]> >> --- >> CC: Jan Beulich <[email protected]> >> CC: Wei Liu <[email protected]> >> CC: Roger Pau Monné <[email protected]> >> CC: Jun Nakajima <[email protected]> >> CC: Kevin Tian <[email protected]> >> CC: Boris Ostrovsky <[email protected]> >> CC: Suravee Suthikulpanit <[email protected]> >> CC: Brian Woods <[email protected]> > [...] > >> diff --git a/xen/arch/x86/vm_event.c b/xen/arch/x86/vm_event.c >> index 15de43c..402f62d 100644 >> --- a/xen/arch/x86/vm_event.c >> +++ b/xen/arch/x86/vm_event.c >> @@ -156,7 +156,7 @@ void vm_event_fill_regs(vm_event_request_t *req) >> req->data.regs.x86.rflags = regs->rflags; >> req->data.regs.x86.rip = regs->rip; >> >> - req->data.regs.x86.dr7 = curr->arch.debugreg[7]; >> + req->data.regs.x86.dr7 = curr->arch.dr7; >> req->data.regs.x86.cr0 = curr->arch.hvm.guest_cr[0]; >> req->data.regs.x86.cr2 = curr->arch.hvm.guest_cr[2]; >> req->data.regs.x86.cr3 = curr->arch.hvm.guest_cr[3]; > I could be wrong, but shouldn't Tamas and me have been CCd as well > because of this change? Not that I have any objections against it. > > Is this a MAINTAINERS / get_maintainer.pl file issue?
Nope sorry - it was a bad edit on my behalf. ~Andrew _______________________________________________ Xen-devel mailing list [email protected] https://lists.xenproject.org/mailman/listinfo/xen-devel
