Re: [PATCH] [PATCH] kvm-userspace: gdb: fix new gdb function types
Christian Ehrhardt wrote: # HG changeset patch # User Christian Ehrhardt ehrha...@linux.vnet.ibm.com # Date 1229085659 -3600 # Node ID 37967a80a2757505488685aac135681945e6da91 # Parent f0ed33f14658fe91a14ec02501cb42d26e32f01f [PATCH] kvm-userspace: gdb: fix new gdb function types From: Christian Ehrhardt ehrha...@linux.vnet.ibm.com The types changed in the header but not in the powerpc and ia64 implementation. This patch fix that build error by changing the stubs to the right prototype. Thanks for the fix! Will merge it into the master patch, adding your signed-off - if that's fine for you. Jan signature.asc Description: OpenPGP digital signature
Re: [PATCH] [PATCH] qemu: ppc: kvm-userspace: KVM PowerPC support for qemu gdbstub
Christian Ehrhardt wrote: Hollis Blanchard wrote: On Thu, 2008-12-11 at 17:05 +0100, Jan Kiszka wrote: Hollis Blanchard wrote: On Thu, 2008-12-11 at 13:53 +0100, Christian Ehrhardt wrote: This is v2 as version one had a type in it occured when splitting patches. Mercurial somehow lost my changes to the patch description explaining that, but the patch is right this way. Christian Ehrhardt wrote: # HG changeset patch # User Christian Ehrhardt ehrhardt-23vcf4htsmix0ybbhkvfkdbpr1lh4...@public.gmane.org # Date 1228999833 -3600 # Node ID dc1466c9077ab162f4637fffee1869f26be02299 # Parent 4c07fe2a56c7653a9113e05bb08c2de9aec210ce [PATCH] qemu: ppc: kvm-userspace: KVM PowerPC support for qemu gdbstub From: Hollis Blanchard hollisb-r/jw6+rmf7hqt0dzr+a...@public.gmane.org Add basic KVM PowerPC support to qemu's gdbstub introducing a kvm ppc style mmu implementation that uses the kvm_translate ioctl. This also requires to save the kvm registers prior to the 'm' gdb operations. Signed-off-by: Hollis Blanchard hollisb-r/jw6+rmf7hqt0dzr+a...@public.gmane.org Signed-off-by: Christian Ehrhardt ehrhardt-23vcf4htsmix0ybbhkvfkdbpr1lh4...@public.gmane.org Let's *not* apply this to kvm-userspace. We will submit this to qemu, and once we work out the right solution there it will be merged naturally. I don't oversee yet what you want to push upstream, but in case it's the gdbstub support for kvm (including ppc bits): please note that I plan to push the new interface once it is merged into kvm-userspace, avoiding to spread the current, limited one as far as possible. BTW, would be great if you could have a look / provide patches for ppc to support the new interface already. I am open for feedback, specifically regarding its suitability beyond x86. I've been meaning to do this for a while, sorry. We'll take a look soon. Hi Jan, I saw that you already had that env-s-g_cpu fix, so if you change all that anyway it might really be better to test/extend your patches for powerpc now. If it is ok for you I would submit my patches that apply on top of yours to you and cc the kvm list. But as Hollis mentioned I would prefer go for qemu upstream first and then assist Avi in merging it into kvm-userspace because this is the natural direction patches flow atm (and if you need to change it multiple times until you get qemu acceptance you would have to extensivly patch both projects to match again). My current roadmap is first merging kernel bits and corresponding kvm-userspace changes so that we can test both extensively in the context of full-blown kvm, and then push an adopted userspace interface into qemu. The other way around would create the risk of missing problems that only pop up under full-featured kvm (upstream is still fairly limited, specifically as there is no threaded smp support). That said, if you have (ppc-)changes that can be pushed immediately and independently, there is surely no need to wait for the kvm-gdb series. As my code in that case depend on your patches it would be nice if you could put them into your series once you are happy with it. I will happily carry them, no problem. Jan signature.asc Description: OpenPGP digital signature
Re: [Qemu-devel] [PATCH 2/6] kvm: sync vcpu state during initialization
Hollis Blanchard wrote: On Fri, 2008-12-12 at 18:23 -0600, Hollis Blanchard wrote: When I use -cpu coreduo (for some strange reason core2duo is not recognized), I don't segfault. I didn't have TARGET_X86_64, so that explains the missing core2duo... I'm a bit confused. You were running -enable-kvm with qemu (as opposed to qemu-system-x86_64)? Regards, Anthony Liguori -- To unsubscribe from this list: send the line unsubscribe kvm-ppc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Qemu-devel] [PATCH 3/6] Enable KVM for ppcemb.
On Thu, 2008-12-11 at 16:54 -0600, Hollis Blanchard wrote: I don't know that kvm_ppc.c is a very information name for this sort of stuff. Since this is really host specific, not target specific, why not move it out of target-ppc. I could combine kvm_ppc.c into target-ppc/kvm.c. However, they're really two different things, and I thought it would cause the least confusion if they were logically separate. Most of it is hooks required by common code, and then some of it isn't. (I'm thinking about e.g. IA64 doing a copy/paste, and then wondering which functions they actually need to implement.) Regardless, I will still need a kvm_ppc.h, so kvm_ppc.c seemed like a good place to match. Any further thoughts on this issue? It's the only issue I still have unresolved from the initial reviews. -- Hollis Blanchard IBM Linux Technology Center -- To unsubscribe from this list: send the line unsubscribe kvm-ppc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Qemu-devel] [PATCH 3/6] Enable KVM for ppcemb.
Hollis Blanchard wrote: On Thu, 2008-12-11 at 16:54 -0600, Hollis Blanchard wrote: I don't know that kvm_ppc.c is a very information name for this sort of stuff. Since this is really host specific, not target specific, why not move it out of target-ppc. I could combine kvm_ppc.c into target-ppc/kvm.c. However, they're really two different things, and I thought it would cause the least confusion if they were logically separate. Most of it is hooks required by common code, and then some of it isn't. (I'm thinking about e.g. IA64 doing a copy/paste, and then wondering which functions they actually need to implement.) Regardless, I will still need a kvm_ppc.h, so kvm_ppc.c seemed like a good place to match. Any further thoughts on this issue? It's the only issue I still have unresolved from the initial reviews. No, we can fix it later when someone comes up with a better idea. Regards, Anthony Liguori -- To unsubscribe from this list: send the line unsubscribe kvm-ppc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
