| |
|
 |
|
 |
|
|
|
| |
|
|
xen-devel
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
|
|
|
| |
|
Home