From mboxrd@z Thu Jan 1 00:00:00 1970 From: Patrick Colp Subject: Re: xenpaging fixes for kernel and hypervisor Date: Wed, 22 Sep 2010 09:49:27 -0700 Message-ID: References: <20100915160521.GA16644@aepfle.de> <20100922154844.GD25088@aepfle.de> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Return-path: In-Reply-To: <20100922154844.GD25088@aepfle.de> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Olaf Hering Cc: xen-devel@lists.xensource.com List-Id: xen-devel@lists.xenproject.org I don't know if I need to ack or not, but I will: Acked-by: Patrick Colp I think the issue with realmode is in the emulation code. Looking at where that crash occurs, it's a result of hvm_emulate_one() returning X86EMUL_UNHANDLEABLE. hvm_emulate_one() calls x86_emulate(), and for supported functions, that will call hvmemul_* using the hvm_emulate_ops pointer function struct. However, my guess is that what's causing this problem is an instruction that isn't handled by that stuff (the hvmemul_* stuff). The way I'd probably go about this is to try to find out what instruction it's trying to emulate when it fails, then to look in the x86_emulate() code and see where/if that instruction is handled. Once that's determined, then you should be able to find out why it's returning X86EMUL_UNHANDLEABLE. Either it's because x86_emulate() doesn't handle it at all (this only seems likely if the paging code has forced the realmode code down a different path, like trying to handle a page fault or something) or the code to handle it assumes that the memory is present in the guest (which was a fair assumption before paging and was a common problem when I was plumbing the rest of the paging code through the emulator). In this case, a check needs to be made to see if the memory the instruction is trying to access is paged out, and if so the result propagated back and everything plumbed through. The convention when emulating and detecting a paged out page is to call p2m_paging_populate and return X86EMUL_RETRY. This should cause the guest/emulate code to just keep retrying the instruction until it succeeds (once the page has been paged back in). There's a chance that the problem occurs when trying to fetch an instruction if that instruction lives on a page that's paged out. I know this case was handled with the regular hvmemul_* code, but not sure if it becomes an issue again with realmode. If you know the instruction or can send me whatever setup you use to cause this bug, then I can help track it down. It sounds from your other e-mails like you've just modified "xm create" to page everything out right away? Patrick On 22 September 2010 08:48, Olaf Hering wrote: > > Patrick, > > there are three more changes to make xenpaging more robust. > Do you need to ack each one to get them merged in xen-unstable? > Should any of these changes go also into the xen-4.0-testing tree for > the 4.0.2 release? If so, I will prepare the patches for this branch. > > > One more thing: In an earlier mail you mentioned that realmode support > is not there yet. However, in my testing I can run grub and the bios and > even boot into Linux a bit. So it appears there is realmode support, > perhaps still incomplete because the guest crashes in (appearently) > early Linux init functions: > > (XEN) realmode.c:115:d1 Failed to emulate insn. > (XEN) realmode.c:165:d1 Real-mode emulation failed @ 9000:0000f81a: 0f 00= 00 00 00 00 > (XEN) domain_crash called from realmode.c:166 > (XEN) Domain 1 (vcpu#0) crashed on cpu#0: > (XEN) ----[ Xen-4.0.1_21326_01-20100922.141534 =C2=A0x86_64 =C2=A0debug= =3Dy =C2=A0Tainted: =C2=A0 =C2=A0C ]---- > (XEN) CPU: =C2=A0 =C2=A00 > (XEN) RIP: =C2=A0 =C2=A09000:[<000000000000f81a>] > (XEN) RFLAGS: 0000000000000246 =C2=A0 CONTEXT: hvm guest > (XEN) rax: 0000000000000000 =C2=A0 rbx: 0000000000008fb8 =C2=A0 rcx: 0000= 000000000000 > (XEN) rdx: 0000000000009000 =C2=A0 rsi: 0000000000000008 =C2=A0 rdi: 0000= 000000099fff > (XEN) rbp: 000000000000ffff =C2=A0 rsp: 0000000000001ff2 =C2=A0 r8: =C2= =A00000000000000000 > (XEN) r9: =C2=A00000000000000000 =C2=A0 r10: 0000000000000000 =C2=A0 r11:= 0000000000000000 > (XEN) r12: 0000000000000000 =C2=A0 r13: 0000000000000000 =C2=A0 r14: 0000= 000000000000 > (XEN) r15: 0000000000000000 =C2=A0 cr0: 0000000000000010 =C2=A0 cr4: 0000= 000000000000 > (XEN) cr3: 0000000000000000 =C2=A0 cr2: 0000000000000000 > (XEN) ds: 0000 =C2=A0 es: 9000 =C2=A0 fs: 9000 =C2=A0 gs: 9000 =C2=A0 ss:= 9000 =C2=A0 cs: 9000 > (XEN) cpupool_rm_domain(dom=3D1,pool=3D0) n_dom 1 > [ =C2=A0127.709423] br0: port 2(vif1.0) entering disabled state > [ =C2=A0127.732999] br0: port 2(vif1.0) entering disabled state > > I'm poking around and adding debug to the gfn_to_mfn* functions, but none= triggers. > Where should I start looking for this kind of bug? > > Olaf > >