Keir/Tim
Why did u add the check in load_seg() function x86_emulate.c:
diff -r 8b152638adaa xen/arch/x86/x86_emulate/x86_emulate.c
--- a/xen/arch/x86/x86_emulate/x86_emulate.c Thu Apr 23 16:22:48 2009 +0100
+++ b/xen/arch/x86/x86_emulate/x86_emulate.c Thu Apr 23 18:47:17 2009 +0100
@@ -1099,7 +1099,7 @@
(ops->write_segment == NULL) )
return X86EMUL_UNHANDLEABLE;
- if ( in_protmode(ctxt, ops) )
+ if ( in_protmode(ctxt, ops) || !is_x86_user_segment(seg) )
return protmode_load_seg(seg, sel, ctxt, ops);
Why is it needed? and what will happen in case we will need to emulate a load of user segment in protected mode? right now, it will just not be performed. is this even legal?
Tom
2009/4/26 Tom Rotenberg
<tom.rotenberg@xxxxxxxxx>
Just saw the reason for the 0xf3 attribute in the Intel Spec.
Sorry...
2009/4/26 Tom Rotenberg
<tom.rotenberg@xxxxxxxxx>
Keir,
I'm trying to figure out what causes the bug i'm experiencing, and i suspect that the TSS patch you have sent me has bugs. I saw in your patch, that you are setting the attributes of the every user segment (including CS) to be 0xf3, which sets the segment type to Data R/W. Don't you need to set the CS segment type to be Code R/W?
Tom
On 23/04/2009 19:00, "Tom Rotenberg" <
tom.rotenberg@xxxxxxxxx> wrote:
> I have applied the patch, and it looks like now it passed this part. However,
> now, it hangs, and doesn't show the PointSec pre-boot GUI. I have also seen
> the following messages in 'xm dmesg':
>
> (XEN) HVM2: Booting from Hard Disk...
> (XEN) HVM2: Booting from 0000:7c00
> (XEN) multi.c:3351:d2 write to pagetable during event injection: cr2=0x2234bc,
> mfn=0x29c23
> (XEN) multi.c:3351:d2 write to pagetable during event injection:
> cr2=0x1032ff8, mfn=0x28e32
> (XEN) multi.c:3351:d2 write to pagetable during event injection:
> cr2=0x102fff8, mfn=0x28e2f
>
> Do u have any idea what may cause this problem?
Those messages are usually rare and typically indicate that a guest
pagetable page has been recycled as a kernel stack page, and is being
written to as part of an exception/interrupt delivery. My guess for why
you're seeing it is that you've entered some horrible exception loop where
the exception handler causes another exception, and this repeats itself.
This would cause the stack to overwrite memory (as exception stack frames
stack up one on top of the other on top of the other...), taking out
pagetable pages as it goes. You'd then hang or crash when enough memory is
overwitten that the exception loop gets broken.
Since the root cause of the exceptions happened some time back in execution,
this could be a pain to debug. :-) And my theory may not even be correct...
-- Keir
