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

Re: [Xen-devel] Re: xenpaging fixes for kernel and hypervisor



All th epatches can be reviewed by tools maintainers and then checked in by
them in their entirety as far as I'm concerned, hypervisor portions
included.

Acked-by: Keir Fraser <keir.fraser@xxxxxxxxxx>

 -- Keir

On 22/09/2010 17:49, "Patrick Colp" <pjcolp@xxxxxxxxx> wrote:

> I don't know if I need to ack or not, but I will:
> 
> Acked-by: Patrick Colp <pjcolp@xxxxxxxxx>
> 
> 
> 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 <olaf@xxxxxxxxx> 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  x86_64  debug=y  Tainted:  
>>  C ]----
>> (XEN) CPU:    0
>> (XEN) RIP:    9000:[<000000000000f81a>]
>> (XEN) RFLAGS: 0000000000000246   CONTEXT: hvm guest
>> (XEN) rax: 0000000000000000   rbx: 0000000000008fb8   rcx: 0000000000000000
>> (XEN) rdx: 0000000000009000   rsi: 0000000000000008   rdi: 0000000000099fff
>> (XEN) rbp: 000000000000ffff   rsp: 0000000000001ff2   r8:  0000000000000000
>> (XEN) r9:  0000000000000000   r10: 0000000000000000   r11: 0000000000000000
>> (XEN) r12: 0000000000000000   r13: 0000000000000000   r14: 0000000000000000
>> (XEN) r15: 0000000000000000   cr0: 0000000000000010   cr4: 0000000000000000
>> (XEN) cr3: 0000000000000000   cr2: 0000000000000000
>> (XEN) ds: 0000   es: 9000   fs: 9000   gs: 9000   ss: 9000   cs: 9000
>> (XEN) cpupool_rm_domain(dom=1,pool=0) n_dom 1
>> [  127.709423] br0: port 2(vif1.0) entering disabled state
>> [  127.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
>> 
>> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@xxxxxxxxxxxxxxxxxxx
> http://lists.xensource.com/xen-devel



_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel


 


Rackspace

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