| |
|
 |
|
 |
|
|
|
| |
|
|
xen-devel
[Xen-devel] Re: xenpaging fixes for kernel and hypervisor
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
|
|
|
| |
|
Home