[Qemu-devel] problem with 64/64 guest running grub

[Qemu-devel] problem with 64/64 guest running grub

[Mike Day]

I'm having a problem with qemu (cvs and 0.8.2) running on a 64 bit
athlon x2 with a 64 bit guest. When installing edgy in a new 64-bit
guest, the guest always freezes when installing grub on the boot
partition. 

This only happens with a 64/64 system. I can run the guest in qemu (as opposed to
qemu-system-x86_64) and use grub to install itself, but if I try to do
the same thing with qemu-system-x86_64 it hangs. 

After generating a trace file and stepping through the hang in gdb it
looks like the guest is getting overwhhelmed with interrupts. It
reminds me of a situation where some device driver is forgetting to
issue an eoi and the interrupt line is remaining on, which means that
the guest can never make any progress advancing the instruction
pointer.

I've placed a compressed log file at
http://www.ncultra.org/qemu.log.tgz

I'd be happy to spend some more time runnign this down - if anyone has
any suggestions on how I should proceed I'd be grateful. 

Mike


-- 
Mike Day
http://www.ncultra.org
AIM: ncmikeday  Yahoo: ultra.runner
PGP key: http://www.ncultra.org/ncmike/pubkey.asc

Re: [Qemu-devel] problem with 64/64 guest running grub

[Werner Dittmann]

Same happen to Suse 64 host/64 guest system (Suse 10.1). A 32-bit
guest system install quite well.

My trace shows the same symptom: Qemu seems to loop in a very tight
loop. Sometimes (using infoe registers rapidly) I can even see that
it seems to switch to 32bit mode inside the guest kernel maybe because
a 32 bit application is running?

No kqemu is involved when running the 64bit guest, started with
-no-kqemu.

As mike wrote: any hint how I can help to tackle the problem is
appreciated.


Regards,
Werner


Mike Day wrote:
> I'm having a problem with qemu (cvs and 0.8.2) running on a 64 bit
> athlon x2 with a 64 bit guest. When installing edgy in a new 64-bit
> guest, the guest always freezes when installing grub on the boot
> partition.
> This only happens with a 64/64 system. I can run the guest in qemu (as
> opposed to
> qemu-system-x86_64) and use grub to install itself, but if I try to do
> the same thing with qemu-system-x86_64 it hangs.
> After generating a trace file and stepping through the hang in gdb it
> looks like the guest is getting overwhhelmed with interrupts. It
> reminds me of a situation where some device driver is forgetting to
> issue an eoi and the interrupt line is remaining on, which means that
> the guest can never make any progress advancing the instruction
> pointer.
> 
> I've placed a compressed log file at
> http://www.ncultra.org/qemu.log.tgz
> 
> I'd be happy to spend some more time runnign this down - if anyone has
> any suggestions on how I should proceed I'd be grateful.
> Mike
> 
> 

[Qemu-devel] Re: problem with 64/64 guest running grub (also 32/64)

[Ludovic Drolez]

Werner Dittmann <Werner.Dittmann <at> t-online.de> writes:
> 
> Same happen to Suse 64 host/64 guest system (Suse 10.1). A 32-bit
> guest system install quite well.

I've also got the problem on a Debian 32 host/64 guest. 
But installing lilo works.
Cheers,

  Ludovic.

Re: [Qemu-devel] problem with 64/64 guest running grub

[Werner Dittmann]

Doing some more tests and trying to get more info about the problem
shows some common behaviours:

- the problems are with the x86_64 emulation regardless if it is
  running on a 32bit or 64bit host (in my case always Linux host)

- The problems happen in all qemu modes: no kqemu, user kqemu, kernel
  kqemu. The main difference: happens on different times during the
  installation process

- It happens (at least this is what I can see) only if the 64 bit kernel
  that runs in qemu-system-x86_64 executes a 32 bit application. For
  example grub is a 32 bit application that runs in the 64bit kernel,
  some installation programs (at least in Suse) are also 32bit applications.

The last statement is supported by the following oberservation: when
Qemu crashes or hangs I very often see some strange register values, for
example:

RBX=ffffffff80523028
RSP=ffffffff80522dc0
RIP=ffffffff8025e67c

If you remove the ff s then you have e.g. a instrution pointer address
that is usually a valid address of a 32bit environment. IMHO something
could be wrong with 32bit support inside qemu-system-x86_64.

Any more ideas where to look to "embrace" the problem?

Regards,
Werner


Werner Dittmann wrote:
> Same happen to Suse 64 host/64 guest system (Suse 10.1). A 32-bit
> guest system install quite well.
> 
> My trace shows the same symptom: Qemu seems to loop in a very tight
> loop. Sometimes (using infoe registers rapidly) I can even see that
> it seems to switch to 32bit mode inside the guest kernel maybe because
> a 32 bit application is running?
> 
> No kqemu is involved when running the 64bit guest, started with
> -no-kqemu.
> 
> As mike wrote: any hint how I can help to tackle the problem is
> appreciated.
> 
> 
> Regards,
> Werner
> 
> 
> Mike Day wrote:
>> I'm having a problem with qemu (cvs and 0.8.2) running on a 64 bit
>> athlon x2 with a 64 bit guest. When installing edgy in a new 64-bit
>> guest, the guest always freezes when installing grub on the boot
>> partition.
>> This only happens with a 64/64 system. I can run the guest in qemu (as
>> opposed to
>> qemu-system-x86_64) and use grub to install itself, but if I try to do
>> the same thing with qemu-system-x86_64 it hangs.
>> After generating a trace file and stepping through the hang in gdb it
>> looks like the guest is getting overwhhelmed with interrupts. It
>> reminds me of a situation where some device driver is forgetting to
>> issue an eoi and the interrupt line is remaining on, which means that
>> the guest can never make any progress advancing the instruction
>> pointer.
>>
>> I've placed a compressed log file at
>> http://www.ncultra.org/qemu.log.tgz
>>
>> I'd be happy to spend some more time runnign this down - if anyone has
>> any suggestions on how I should proceed I'd be grateful.
>> Mike
>>
>>
> 
> 
> 
> _______________________________________________
> Qemu-devel mailing list
> Qemu-devel@nongnu.org
> http://lists.nongnu.org/mailman/listinfo/qemu-devel
>