On 06/04/2010 09:53 AM, Paolo Bonzini wrote:
On 06/03/2010 09:59 PM, Igor Kovalenko wrote:
On Thu, Jun 3, 2010 at 7:42 PM, Paolo Bonzini<pbonz...@redhat.com> wrote:
On 06/03/2010 05:25 PM, Alexander Graf wrote:
Am 03.06.2010 um 15:18 schrieb Paolo Bonzini<pbonz...@redhat.com>:
On 06/01/2010 10:12 PM, Igor V. Kovalenko wrote:
From: Igor V. Kovalenko<igor.v.kovale...@gmail.com>
- change return type of ldl_* to uint32_t to prevent unwanted sign
extension
visible in sparc64 load alternate address space methods
- note this change makes ldl_* softmmu implementations match ldl_phys
one
This patch breaks -kernel/-initrd.
Breaks it where and when?
x86_64 TCG reboots after the "Probing EDD" step.
My local build appears to work, qemu-system-x86_64 loads my gentoo
linux setup.
I use x86_64 host, gcc 4.4.3, qemu configured with ./configure
--prefix=/inst --target-list=sparc64-softmmu,x86_64-softmmu
Normal boot works. Only -kernel/-initrd fails.
Hmm, PEBKAC. Boot of Fedora and RHEL5 guests always fails, so it's not
related to -kernel/-initrd. (Of course, without -kernel/-initrd it
reboots into GRUB rather than looping quickly).
I've placed a failing vmlinuz at
http://people.redhat.com/people/vmlinuz-fail -- if it fails it should
reboot continuously. The failure happens pretty soon after the kernel
starts running. The sequence is:
lock_kernel
-> __lock_kernel
-> preempt_disable
-> current_thread_info()
IN:
0xffffffff80063064: push %rbp
0xffffffff80063065: mov %rsp,%rbp
0xffffffff80063068: mov %gs:0x10,%rax
0xffffffff80063071: mov -0x1fc8(%rax),%eax
0xffffffff80063077: test $0x8,%al
0xffffffff80063079: je 0xffffffff800630a2
%rax is 0xffffffff803f1fd8, but it page faults with
%cr2=0x00000000803f0010. The reason is that in the generated x86
assembly -0x1fc8 is erroneously zero extended:
0x4180347b: mov %rbp,%rbx
0x4180347e: mov $0xffffe038,%r12d
0x41803484: add %r12,%rbx
so it gives the wrong address:
(gdb) info reg rbp
rbp 0xffffffff803f1fd8 0xffffffff803f1fd8
(gdb) info reg r12
r12 0xffffe038 4294959160
(gdb) info reg rbx
rbx 0x803f0010 2151612432
From there it's obvious: general protection, double fault, general
protection, triple fault.
So it's a TCG bug that is expecting ldl_* to sign extend. I'll send a
patch after I come back from lunch.
Paolo