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

Nope sorry - it was a bad edit on my behalf.

~Andrew

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

Reply via email to