Re: [Qemu-devel] [PATCH] monitor: Add port write command

[Gleb Natapov <gleb@redhat.com>]

On Wed, Jul 15, 2009 at 12:40:49PM +0200, Jan Kiszka wrote:
> Paul Brook wrote:
> >>> I'd be reluctant to expose the savevm state to the user.
> >>>
> >>> For debugging qemu I don't see it providing any real benefit over firing
> >>> up GDB and poking directly at the device directly.
> >> Not all environments where you need to debug things have gdb, qemu
> >> sources or even non striped qemu binary.
> > 
> > If you don't have qemu sources than I really don't care. By definition you're 
> > not going to be able to do anything useful even if you do figure out what the 
> > problem is.  Note that there's no requirement that you run gdb on the target 
> > itself. Remote debug (e.g. via gdbserver on linux) is a well established 
> > technique.
> > 
> > Likewise for debugging stripped production binaries, my answer is "don't do 
> > that". There are very rare cases where a bug goes away on a debug build, but 
> > in those cases any instrumentation you add is also liable to make the bug go 
> > away.
> 
> Again, having to debug qemu itself when all you want is some additional
> information about the emulated hardware state while debugging a guest
> seems like overkill to me. Imagine you are attached to qemu's gdbstub
> and stopped the guest that has some issue using, say, the apic. And now
> imagine you could simply issue e.g.
> 
> (gdb) monitor devstate apic.1
> apicbase=...
> tpr=...
> icr={..., ... }
> lvt={..., ... }
> ...
> 
> That would provide you a nice picture of the virtual hardware state
> without the need to fire up and operate a second gdb just to obtain this
> data. And manipulating some lvt register would only be a trivial
> additional monitor command away.
> 
apic/ioapic is important enough to warrant "info apic" "info ioapic"
commands.

--
			Gleb.