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 <ta...@tklengyel.com>
Cc: Razvan Cojocaru <rcojoc...@bitdefender.com>
Cc: Tamas K Lengyel <ta...@tklengyel.com>
Cc: Jan Beulich <jbeul...@suse.com>
Cc: Andrew Cooper <andrew.coop...@citrix.com>
Cc: Wei Liu <wei.l...@citrix.com>
Cc: Roger Pau Monne <roger....@citrix.com>
---
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. 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.
Petre is currently working on the vm_event changes that will hopefully
enable us to just cache everything that the getcontext_partial hypercall
retrieves.
Thanks,
Razvan
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
