Re: xenpaging fixes for kernel and hypervisor

[Patrick Colp <pjcolp@cs.ubc.ca>]

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
>
>