[Crash-utility] [PATCH] bug on get_be_long() and improvement of bt

[Hu Tao]

On Wed, Oct 20, 2010 at 09:11:02AM -0400, Dave Anderson wrote:
> 
> ----- "Hu Tao" <hutao at cn.fujitsu.com> wrote:
> 
> > On Tue, Oct 19, 2010 at 09:06:33AM -0400, Dave Anderson wrote:
> > > 
> > > ----- "Hu Tao" <hutao at cn.fujitsu.com> wrote:
> > > 
> > > > Hi Dave,
> > > > 
> > > >    These are updated patches tested with SMP system and panic
> > task.
> > > > 
> > > >    When testing a x86 guest, I found another bug about reading cpu
> > > >    registers from dumpfile. Qemu simulated system is x86_64 
> > > >    (qemu-system-x86_64), guest OS is x86. When crash reads cpu registers
> > > >    from dumpfile, it uses cpu_load_32(), this will read gp registers by
> > > >    get_be_long(fp, 32), that is, treate them as 32bits. But in fact,
> > > >    qemu-system-x86_64 saves 64bits for each of them(although guest OS
> > > >    uses only lower 32 bits). As a result, crash gets wrong cpu gp
> > > >    register values.
> > > 
> > > As I understand it, you're running a 32-bit guest on a 64-bit host.
> > 
> > Yes.
> > 
> > > If you were to read 64-bit register values instead of 32-bit register
> > > values, wouldn't that cause the file offsets of the subsequent get_xxx()
> > > calls in cpu_load() to read from the wrong file offsets?  And then
> > > that would leave the ending file offset incorrect, such that the 
> > > qemu_load() loop would fail to find the next device?
> > > 
> > > In other words, the cpu_load() function, which is used for both
> > > 32-bit and 64-bit guests, must be reading the correct amount of
> > > data from the "cpu" device, or else qemu_load() would fail to
> > > find the next device in the next location in the dumpfile.  
> > 
> > True. In fact, in my case if read 32-bit registers, following devices
> > are found:
> >     block, ram, kvm-tpr-opt, kvmclock, timer, cpu_common, cpu.
> > If read 64-bit registers, following devices are found:
> >     block, ram, kvm-tpr-opt, kvmclock, timer, cpu_common, cpu, apic, fw_cfg
> 
> Right -- so it got "lost" after incorrectly gathering the data for the
> first "cpu" device instance.
> 
> > > >    Is there any way we can know from dumpfile that these gp
> > > >    registers(and those similar registers) are 32bits or 64bits?
> > > 
> > > I don't know.  If what you say is true, when would those registers
> > > ever be 32-bit values?
> > 
> > I did tests on a 64-bit machine. Result is:
> > 
> > machine		OS	guest machine		guest OS	saved gp regs
> > ------------------------------------------------------------------------
> > 64-bit		x86	qemu-kvm(kvm enabled)	x86		64 bits
> > 64-bit		x86	qemu(kvm disabled)	x86		32 bits
> 
> I don't understand what you mean when you say that the guest machine
> is "kvm enabled" or "kvm disabled"?

Sorry for being vague. "kvm enabled"  means using qemu-kvm to bring up
guest machine and this enables KVM hardware virtualization on host.
"kvm disabled"  means using qemu to bring up guest machine and this
disables KVM hardware virtualization on host.

> 
> And if your host machine is running a 32-bit x86 OS (on 64-bit hardware),
> that's something I've never seen given that Red Hat only allows 64-bit
> kernels as KVM hosts.

I did the test on Fedora 13 i686. Just tried rhel6 i386, as you said,
there is no kvm support.

-- 
Thanks,
Hu Tao