Re: [Xen-devel] [PATCH] x86/vm_event: add gdtr_base to the vm_event structure

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 02.05.19 at 10:25, <rcojocaru@xxxxxxxxxxxxxxx> wrote:
> On 5/2/19 2:57 AM, Tamas K Lengyel wrote:
>> Receiving this register is useful for introspecting 32-bit Windows when the
>> event being trapped happened while in ring3.
>> 
>> Signed-off-by: Tamas K Lengyel <tamas@xxxxxxxxxxxxx>
>> Cc: Razvan Cojocaru <rcojocaru@xxxxxxxxxxxxxxx>
>> Cc: Tamas K Lengyel <tamas@xxxxxxxxxxxxx>
>> Cc: Jan Beulich <jbeulich@xxxxxxxx>
>> Cc: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
>> Cc: Wei Liu <wei.liu2@xxxxxxxxxx>
>> Cc: Roger Pau Monne <roger.pau@xxxxxxxxxx>
>> ---
>>   xen/arch/x86/vm_event.c       | 5 +++++
>>   xen/include/public/vm_event.h | 3 ++-
>>   2 files changed, 7 insertions(+), 1 deletion(-)
>> 
>> diff --git a/xen/arch/x86/vm_event.c b/xen/arch/x86/vm_event.c
>> index 51c3493b1d..873788e32f 100644
>> --- a/xen/arch/x86/vm_event.c
>> +++ b/xen/arch/x86/vm_event.c
>> @@ -179,6 +179,10 @@ static void vm_event_pack_segment_register(enum 
> x86_segment segment,
>>           reg->es_sel = seg.sel;
>>           break;
>>   
>> +    case x86_seg_gdtr:
>> +        reg->gdtr_base = seg.base;
>> +        break;
> 
> Please also add limit, ar, sel, like the others do.

There's no ar or sel for GDT (and IDT). Instead, because of ...

> In addition to 
> making this modification look less strange (since, in contrast to the 
> function name, nothing is packed for gdtr_base), it will also save 
> future work for applications wanting to use gdtr which also require 
> backwards compatibility with previous vm_event versions.
> 
> As you know, for each such modification we need to have a separate 
> vm_event_vX header in our applications so that we're ready to create a 
> ring buffer using requests and replies of the right size, and also to be 
> able to properly interpret the ring buffer data, so the least frequent 
> changes to the vm_event struct, the better.

... this I wonder whether the IDT details shouldn't get added at
the same time.

Jan



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