>While we tried to make debugging inside the guest work, this >was never really tested, so it's likely broken. I'll try to >look at what it will take to make it work; I don't think there's >much needed.
That sounds encouraging -- I had imagined there might be some "impossibility factor" in sharing something like hardware breakpoints between host and guest. For now I'm simply sticking to QEMU+kqemu when I expect deliberate trickiness or need to do hard-breakpoint debugging, and QEMU/KVM (which is up to 50% faster when doing Windows software builds on my PC, nice!) when I don't care. I haven't had any problems loading and using the kvm drivers and kqemu at the same time, and I have assumed that there ought to be no issues in doing so, since they work quite differently and (from my very dangerously limited understanding) ought not to be competing for any mutually exclusive hardware resources. Is that a reasonable assumption? >What hardware are you using? If you have both AMD and Intel >hardware, you might have better luck switching, since this is >very subarch dependent. Intel Core Duo (T2400 @ 1.83GHz according to /proc/cpuinfo), running 32-bit Linux 2.6.21.5 using KVM drivers built from the kvm-59 sourceball. Sorry, I don't have other vendors or CPU bitnesses to test on. PS: When I build KVM "out of the box," I get a qemu binary called qemu-system-x86_64, though I have a 32-bit CPU and a 32-bit OS. Forgive my ignorance on this, but...why does the name of the binary imply a 64-bit flavour? ------------------------------------------------------------------------- Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace _______________________________________________ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
