Re: [Qemu-devel] [PATCH 2/6] kvm: sync vcpu state during initialization
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... -- 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 2/6] kvm: sync vcpu state during initialization
On Thu, 2008-12-11 at 15:24 -0600, Anthony Liguori wrote: > Hollis Blanchard wrote: > > Currently on x86, qemu initializes CPUState but KVM ignores it and does its > > own vcpu initialization. However, PowerPC KVM needs to be able to set the > > initial register state to support the -kernel and -append options. > > > > Signed-off-by: Hollis Blanchard > > > > Segv's x86 when using -enable-kvm. qemu.git already segvs on x86 with --enable-kvm unless you specify a -cpu option. (I'd call that a bug.) Maybe you forgot that on this run? When I use "-cpu coreduo" (for some strange reason "core2duo" is not recognized), I don't segfault. -- 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
[PATCH] [PATCH] kvm-userspace: gdb: fix new gdb function types
# HG changeset patch
# User Christian Ehrhardt
# Date 1229085659 -3600
# Node ID 37967a80a2757505488685aac135681945e6da91
# Parent f0ed33f14658fe91a14ec02501cb42d26e32f01f
[PATCH] kvm-userspace: gdb: fix new gdb function types
From: Christian Ehrhardt
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.
Signed-off-by: Christian Ehrhardt
---
[diffstat]
qemu-kvm-ia64.c|6 --
qemu-kvm-powerpc.c |6 --
2 files changed, 8 insertions(+), 4 deletions(-)
[diff]
diff --git a/qemu/qemu-kvm-ia64.c b/qemu/qemu-kvm-ia64.c
--- a/qemu/qemu-kvm-ia64.c
+++ b/qemu/qemu-kvm-ia64.c
@@ -65,12 +65,14 @@ void kvm_arch_update_regs_for_sipi(CPUSt
{
}
-int kvm_arch_insert_sw_breakpoint(struct kvm_sw_breakpoint *bp)
+int kvm_arch_insert_sw_breakpoint(CPUState *current_env,
+ struct kvm_sw_breakpoint *bp)
{
return -EINVAL;
}
-int kvm_arch_remove_sw_breakpoint(struct kvm_sw_breakpoint *bp)
+int kvm_arch_remove_sw_breakpoint(CPUState *current_env,
+ struct kvm_sw_breakpoint *bp)
{
return -EINVAL;
}
diff --git a/qemu/qemu-kvm-powerpc.c b/qemu/qemu-kvm-powerpc.c
--- a/qemu/qemu-kvm-powerpc.c
+++ b/qemu/qemu-kvm-powerpc.c
@@ -223,12 +223,14 @@ void kvm_arch_cpu_reset(CPUState *env)
{
}
-int kvm_arch_insert_sw_breakpoint(struct kvm_sw_breakpoint *bp)
+int kvm_arch_insert_sw_breakpoint(CPUState *current_env,
+ struct kvm_sw_breakpoint *bp)
{
return -EINVAL;
}
-int kvm_arch_remove_sw_breakpoint(struct kvm_sw_breakpoint *bp)
+int kvm_arch_remove_sw_breakpoint(CPUState *current_env,
+ struct kvm_sw_breakpoint *bp)
{
return -EINVAL;
}
--
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: [PATCH] [PATCH] qemu: ppc: kvm-userspace: KVM PowerPC support for qemu gdbstub
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 # Date 1228999833 -3600 # Node ID dc1466c9077ab162f4637fffee1869f26be02299 # Parent 4c07fe2a56c7653a9113e05bb08c2de9aec210ce [PATCH] qemu: ppc: kvm-userspace: KVM PowerPC support for qemu gdbstub From: Hollis Blanchard 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 Signed-off-by: Christian Ehrhardt 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). 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. -- Grüsse / regards, Christian Ehrhardt IBM Linux Technology Center, Open Virtualization -- 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: [PATCH 03/11] Use arch.pid as shadow pid for E500
> -Original Message- > From: kvm-ppc-ow...@vger.kernel.org > [mailto:kvm-ppc-ow...@vger.kernel.org] On Behalf Of Liu Yu-B13201 > Sent: Friday, December 12, 2008 10:21 AM > To: Hollis Blanchard > Cc: kvm-ppc@vger.kernel.org > Subject: RE: [PATCH 03/11] Use arch.pid as shadow pid for E500 > > > > -Original Message- > > From: kvm-ppc-ow...@vger.kernel.org > > [mailto:kvm-ppc-ow...@vger.kernel.org] On Behalf Of Hollis Blanchard > > Sent: Friday, December 12, 2008 5:02 AM > > To: Liu Yu-B13201 > > Cc: kvm-ppc@vger.kernel.org > > Subject: Re: [PATCH 03/11] Use arch.pid as shadow pid for E500 > > > > On Thu, 2008-12-11 at 17:11 +0800, Liu Yu wrote: > > > Signed-off-by: Liu Yu > > > --- > > > arch/powerpc/kernel/asm-offsets.c |8 +++- > > > 1 files changed, 7 insertions(+), 1 deletions(-) > > > > > > diff --git a/arch/powerpc/kernel/asm-offsets.c > > b/arch/powerpc/kernel/asm-offsets.c > > > index 544a27f..79fe94c 100644 > > > --- a/arch/powerpc/kernel/asm-offsets.c > > > +++ b/arch/powerpc/kernel/asm-offsets.c > > > @@ -355,6 +355,13 @@ int main(void) > > > DEFINE(PTE_SIZE, sizeof(pte_t)); > > > > > > #ifdef CONFIG_KVM > > > +#ifdef CONFIG_44x > > > + DEFINE(VCPU_SHADOW_PID, offsetof(struct kvm_vcpu, > > arch.shadow_pid)); > > > +#endif > > > +#ifdef CONFIG_FSL_BOOKE > > > + DEFINE(VCPU_SHADOW_PID, offsetof(struct kvm_vcpu, arch.pid)); > > > +#endif > > > + > > > DEFINE(VCPU_HOST_STACK, offsetof(struct kvm_vcpu, > > arch.host_stack)); > > > DEFINE(VCPU_HOST_PID, offsetof(struct kvm_vcpu, arch.host_pid)); > > > DEFINE(VCPU_GPRS, offsetof(struct kvm_vcpu, arch.gpr)); > > > @@ -368,7 +375,6 @@ int main(void) > > > DEFINE(VCPU_SPRG5, offsetof(struct kvm_vcpu, arch.sprg5)); > > > DEFINE(VCPU_SPRG6, offsetof(struct kvm_vcpu, arch.sprg6)); > > > DEFINE(VCPU_SPRG7, offsetof(struct kvm_vcpu, arch.sprg7)); > > > - DEFINE(VCPU_SHADOW_PID, offsetof(struct kvm_vcpu, > > arch.shadow_pid)); > > > > > > DEFINE(VCPU_LAST_INST, offsetof(struct kvm_vcpu, > > arch.last_inst)); > > > DEFINE(VCPU_FAULT_DEAR, offsetof(struct kvm_vcpu, > > arch.fault_dear)); > > > > I can commit this, but we got a significant performance boost from > > implementing the shadow_pid scheme. Do you think implementing > > that would > > be difficult? > > > > Not difficult. > But I want to compare it with some other ways before apply it. > > As you know, E500 has a large TLB0, so it has more room to handle > multi-VMs on a single core. > Current shadow pid trick indeed boost performance in the case > of one VM, > but for multi-VMs, your pid mapping idea seems better for E500. I can use arch.shadow_pid, however I will keep arch.shadow_pid equal to arch.pid. What do you think? -- 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
