[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

On 5/2/19 11:52 AM, Andrew Cooper wrote:
On 02/05/2019 09:25, Razvan Cojocaru 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;
   +    case x86_seg_gdtr:
+        reg->gdtr_base = seg.base;
+        break;

Please also add limit, ar, sel, like the others do.

In Xen, we model GDTR/IDTR just like all other segments in the segment
cache for convenience/consistency, including faking up of some default

However, there is no such thing as a selector or access rights for them,
and the VMCS lacks the fields, while the VMCB marks the fields as
reserved.   It is almost certainly not worth wasting the space in the ring.

Right, I got carried away there: I saw gdtr_limit and didn't check that if the rest is available.


Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.