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 <andrew.coop...@citrix.com>
> ---
> CC: Jan Beulich <jbeul...@suse.com>
> CC: Wei Liu <wei.l...@citrix.com>
> CC: Roger Pau Monné <roger....@citrix.com>
> CC: Jun Nakajima <jun.nakaj...@intel.com>
> CC: Kevin Tian <kevin.t...@intel.com>
> CC: Boris Ostrovsky <boris.ostrov...@oracle.com>
> CC: Suravee Suthikulpanit <suravee.suthikulpa...@amd.com>
> CC: Brian Woods <brian.wo...@amd.com>

[...]

> 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?


Thanks,
Razvan

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Reply via email to