<html><head><style type='text/css'>p { margin: 0; }</style></head><body><div style='font-family: Times New Roman; font-size: 12pt; color: #000000'><br> Unless you can provide a reproduction scenario, I don't think we'll look at the patch. "Android" is no better than "Linux". A preconfigured VM would be acceptable if you can't provide any real information.<br><br> - Michal<br><br>----- Original Message -----<br>From: manjian2006@gmail.com<br>To: michal.necasek@oracle.com, vbox-dev@virtualbox.org<br>Sent: Thursday, December 24, 2015 11:29:43 AM GMT +01:00 Amsterdam / Berlin / Bern / Rome / Stockholm / Vienna<br>Subject: 回复: [vbox-dev] GDT entries syncing between qemu mode & raw mode bug<br><br>android x86<br><br>来自我的华为手机<div><div class="quote" style="line-height: 1.5"><br><br>-------- 原始邮件 --------<br>主题:Re: [vbox-dev] GDT entries syncing between qemu mode & raw mode bug<br>发件人:Michal Necasek <br>收件人:vbox-dev@virtualbox.org<br>抄送:<br><br><br><blockquote class="quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br> This doesn't look unreasonable, but one important thing is missing: How exactly do we reproduce the problem? If we can't reproduce it, we can't verify that the patch does anything useful. I'm sure you know that "linux" is not a particularly accurate description of the guest OS.<br><br> Thanks,<br> Michal<br><br>----- Original Message -----<br>From: manjian2006@gmail.com<br>To: vbox-dev@virtualbox.org<br>Sent: Thursday, December 24, 2015 4:23:56 AM GMT +01:00 Amsterdam / Berlin / Bern / Rome / Stockholm / Vienna<br>Subject: [vbox-dev] GDT entries syncing between qemu mode & raw mode bug<br><br>Hi friends,<br> When I turn off the vt of my machine, my linux occasionally meets<br> a coredump, which eip points to the following something like this:<br> movl %ecx, %gs:0<br> And that's the tls of linux conventions controlled by gdt.<br> And the wired thing is that when a gdb attached into the<br> will-coredump process, and enter 'continue', the process that should<br> trigger coredump continues to run normally.<br> I guess this is a syncing bug between raw mode and qemu mode, So I<br> add patch like following:<br>diff --git a/src/recompiler/VBoxRecompiler.c b/src/recompiler/VBoxRecompiler.c<br>index d74eeb0..fdba032 100644<br>--- a/src/recompiler/VBoxRecompiler.c<br>+++ b/src/recompiler/VBoxRecompiler.c<br>@@ -2063,6 +2063,7 @@ void remR3RecordCall(CPUX86State *env)<br> #endif<br> }<br> <br>+#define DEEP_SYNC_SEGMENT_REG /* add by linsh for VT */<br> <br> /**<br> * Syncs the internal REM state with the VM.<br>@@ -2089,7 +2090,14 @@ REMR3DECL(int) REMR3State(PVM pVM, PVMCPU pVCpu)<br> uint8_t u8TrapNo;<br> uint32_t uCpl;<br> int rc;<br>+#ifdef DEEP_SYNC_SEGMENT_REG /* add by linsh for VT */<br> <br>+ VBOXGDTR GDTR;<br>+ RTGCPTR GCPtrGDT;<br>+ unsigned iGDT;<br>+ unsigned cGDTs;<br>+<br>+#endif<br> STAM_PROFILE_START(&pVM->rem.s.StatsState, a);<br> Log2(("REMR3State:\n"));<br> <br>@@ -2406,7 +2414,52 @@ REMR3DECL(int) REMR3State(PVM pVM, PVMCPU pVCpu)<br> SYNC_IN_SREG(&pVM->rem.s.Env, GS, &pVM->rem.s.Env.segs[R_GS], &pCtx->gs);<br> /** @todo need to find a way to communicate potential GDT/LDT changes and thread switches. The selector might<br> * be the same but not the base/limit. */<br>+#ifdef DEEP_SYNC_SEGMENT_REG /* add by linsh for VT */<br> <br>+/*<br>+*Check for the base address of the SegmentCache<br>+*/<br>+#define DEEP_SYNC_SEG_REG(a_pRemSReg,a_SReg,a_pVBoxSReg,a_pGDTE,a_Sel) \<br>+ do \<br>+ { \<br>+ if (a_Sel == (((a_pVBoxSReg)->Sel) >> 3)/* && (a_Sel == 6 || a_Sel == 7) */) \<br>+ { \<br>+ if ((a_pRemSReg)->base != X86DESC_BASE(a_pGDTE) ) \<br>+ { \<br>+ Log2(("REMR3State: " #a_SReg " base had changed from %08x to %08x!\n", \<br>+ (a_pRemSReg)->base, X86DESC_BASE(a_pGDTE))); \<br>+ (a_pRemSReg)->base = X86DESC_BASE(a_pGDTE); \<br>+ (a_pRemSReg)->limit = X86DESC_LIMIT_G(a_pGDTE); \<br>+ } \<br>+ } \<br>+ } while (0)<br>+<br>+ /* Get the GDTR */<br>+ CPUMGetGuestGDTR(pVCpu, &GDTR);<br>+ if (GDTR.cbGdt < sizeof(X86DESC))<br>+ {<br>+ Log2(("REMR3State: No GDT entries...\n"));<br>+ return VINF_SUCCESS;<br>+ }<br>+<br>+ GCPtrGDT = GDTR.pGdt;<br>+ cGDTs = ((unsigned)GDTR.cbGdt + 1) / sizeof(X86DESC);<br>+<br>+ for (iGDT = 0; iGDT < cGDTs; iGDT++, GCPtrGDT += sizeof(X86DESC))<br>+ {<br>+ X86DESC GDTE;<br>+ int rc = PGMPhysSimpleReadGCPtr(pVCpu, &GDTE, GCPtrGDT, sizeof(GDTE));<br>+ if (RT_SUCCESS(rc))<br>+ {<br>+ if (GDTE.Gen.u1Present)<br>+ {<br>+ Log2(("REMR3State: iGDT:%d,base:%08x,limit:%08x\n",iGDT,X86DESC_BASE(&GDTE),X86DESC_LIMIT_G(&GDTE))); <br>+ DEEP_SYNC_SEG_REG(&pVM->rem.s.Env.segs[R_GS], GS, &pCtx->gs, &GDTE, iGDT );<br>+ }<br>+ }<br>+ }<br>+ <br>+#endif<br><br> The coredump never ever happend again.<br>--<br>Lin Zuojian<br><br>_______________________________________________<br>vbox-dev mailing list<br>vbox-dev@virtualbox.org<br>https://www.virtualbox.org/mailman/listinfo/vbox-dev<br><br>_______________________________________________<br>vbox-dev mailing list<br>vbox-dev@virtualbox.org<br>https://www.virtualbox.org/mailman/listinfo/vbox-dev<br></blockquote></div></div></div></body></html>