Re: Re: xenpaging fixes for kernel and hypervisor

[Keir Fraser <keir.fraser@eu.citrix.com>]

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@citrix.com>

 -- Keir

On 22/09/2010 17:49, "Patrick Colp" <pjcolp@cs.ubc.ca> wrote:

> I don't know if I need to ack or not, but I will:
> 
> Acked-by: Patrick Colp <pjcolp@cs.ubc.ca>
> 
> 
> 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@aepfle.de> 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@lists.xensource.com
> http://lists.xensource.com/xen-devel