Re: [PATCH 03/18] KVM: PPC: Teach MMIO Signedness
On 02/07/2010 03:35 PM, Alexander Graf wrote: It's technically implementation dependent but I don't know of an implementation that doesn't sign extend. Hrm, would gpr = (s64)(s32)gpr; work? :) Yes. Integer promotion does guarantee sign extension. Regards, Anthony Liguori Alex -- 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 00/18] KVM: PPC: Virtualize Gekko guests
Avi Kivity wrote: > On 02/07/2010 05:49 PM, Alexander Graf wrote: >> Am 07.02.2010 um 13:54 schrieb Avi Kivity : >> >>> On 02/04/2010 05:55 PM, Alexander Graf wrote: In an effort to get KVM on PPC more useful for other userspace users than Qemu, I figured it'd be a nice idea to implement virtualization of the Gekko CPU. The Gekko is the CPU used in the GameCube. In a slightly more modern fashion it lives on in the Wii today. Using this patch set and a modified version of Dolphin, I was able to virtualize simple GameCube demos on a 970MP system. As always, while getting this to run I stumbled across several broken parts and fixed them as they came up. So expect some bug fixes in this patch set too. >>> >>> This is halfway into emulation rather than virtualization. What >>> does performance look like when running fpu intensive applications? >> >> It is for the FPU. It is not for whatever runs on the CPU. >> >> I haven't benchmarked things so far, >> >> The only two choices I have to get this running is in-kernel >> emulation or userspace emulation. According to how x86 deals with >> things I suppose full state transition to userspace and continuing >> emulation there isn't considered a good idea. So I went with in-kernel. > > It's not a good idea for the kernel either, if it happens all the > time. If a typical Gekko application uses the fpu and the emulated > instructions intensively, performance will suck badly (as in: qemu/tcg > will be faster). > Yeah, I haven't really gotten far enough to run full-blown guests yet. So far I'm on demos and they look pretty good. But as far as intercept speed goes - I just tried running this little piece of code in kvmctl: .global _start _start: lir3, 42 mtsprg0, r3 mfsprgr4, 0 b_start and measured the amount of exits I get on my test machine: processor: 0 cpu: PPC970MP, altivec supported clock: 2500.00MHz revision: 1.1 (pvr 0044 0101) ---> exits 1811108 I have no idea how we manage to get that many exits, but apparently we are. So I'm less concerned about the speed of the FPU rerouting at the moment. If it really gets unusably slow, I'd rather binary patch the guest on the fly in KVM according to rules set by the userspace client. But we'll get there when it turns out to be too slow. For now I'd rather like to have something working at all and then improve speed :-). Alex -- 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/18] KVM: PPC: Teach MMIO Signedness
Am 07.02.2010 um 17:27 schrieb Anthony Liguori :
On 02/07/2010 06:32 AM, Avi Kivity wrote:
On 02/04/2010 05:55 PM, Alexander Graf wrote:
The guest I was trying to get to run uses the LHA and LHAU
instructions.
Those instructions basically do a load, but also sign extend the
result.
Since we need to fill our registers by hand when doing MMIO, we
also need
to sign extend manually.
This patch implements sign extended MMIO and the LHA(U)
instructions.
@@ -300,6 +300,25 @@ static void kvmppc_complete_mmio_load(struct
kvm_vcpu *vcpu,
}
}
+if (vcpu->arch.mmio_sign_extend) {
+switch (run->mmio.len) {
+#ifdef CONFIG_PPC64
+case 4:
+if (gpr& 0x8000)
+gpr |= 0xULL;
+break;
Wouldn't
gpr = (s64)(gpr << 32) >> 32;
work? Not sure if >> is guaranteed to sign extend.
It's technically implementation dependent but I don't know of an
implementation that doesn't sign extend.
Hrm, would
gpr = (s64)(s32)gpr;
work? :)
Alex
--
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/18] KVM: PPC: Teach MMIO Signedness
On 02/07/2010 06:32 AM, Avi Kivity wrote:
On 02/04/2010 05:55 PM, Alexander Graf wrote:
The guest I was trying to get to run uses the LHA and LHAU instructions.
Those instructions basically do a load, but also sign extend the result.
Since we need to fill our registers by hand when doing MMIO, we also
need
to sign extend manually.
This patch implements sign extended MMIO and the LHA(U) instructions.
@@ -300,6 +300,25 @@ static void kvmppc_complete_mmio_load(struct
kvm_vcpu *vcpu,
}
}
+if (vcpu->arch.mmio_sign_extend) {
+switch (run->mmio.len) {
+#ifdef CONFIG_PPC64
+case 4:
+if (gpr& 0x8000)
+gpr |= 0xULL;
+break;
Wouldn't
gpr = (s64)(gpr << 32) >> 32;
work? Not sure if >> is guaranteed to sign extend.
It's technically implementation dependent but I don't know of an
implementation that doesn't sign extend.
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: [PATCH 00/18] KVM: PPC: Virtualize Gekko guests
On 02/07/2010 05:49 PM, Alexander Graf wrote: Am 07.02.2010 um 13:54 schrieb Avi Kivity : On 02/04/2010 05:55 PM, Alexander Graf wrote: In an effort to get KVM on PPC more useful for other userspace users than Qemu, I figured it'd be a nice idea to implement virtualization of the Gekko CPU. The Gekko is the CPU used in the GameCube. In a slightly more modern fashion it lives on in the Wii today. Using this patch set and a modified version of Dolphin, I was able to virtualize simple GameCube demos on a 970MP system. As always, while getting this to run I stumbled across several broken parts and fixed them as they came up. So expect some bug fixes in this patch set too. This is halfway into emulation rather than virtualization. What does performance look like when running fpu intensive applications? It is for the FPU. It is not for whatever runs on the CPU. I haven't benchmarked things so far, The only two choices I have to get this running is in-kernel emulation or userspace emulation. According to how x86 deals with things I suppose full state transition to userspace and continuing emulation there isn't considered a good idea. So I went with in-kernel. It's not a good idea for the kernel either, if it happens all the time. If a typical Gekko application uses the fpu and the emulated instructions intensively, performance will suck badly (as in: qemu/tcg will be faster). -- error compiling committee.c: too many arguments to function -- 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 18/18] KVM: PPC: Implement Paired Single emulation
On 02/07/2010 05:57 PM, Alexander Graf wrote:+ +dprintk(KERN_INFO "FPU Emulator 0x%x ( 0x%llx, 0x%llx, 0x%llx )", inst, +inout[1], inout[2], inout[3]); + +call_stack =&kvmppc_call_stack[(smp_processor_id() * 2)]; +call_stack[0] = inst; +/* call_stack[1] is INS_BLR */ + Would be easier on the cache to do this per-cpu? It is per-cpu. Or do you mean to actually use the PER_CPU definition? Is that guaranteed to be executable? I meant, per-cpu vmalloc area, but it should be enough to have a per-cpu cache line. -- error compiling committee.c: too many arguments to function -- 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/18] KVM: PPC: Teach MMIO Signedness
On 02/07/2010 05:51 PM, Alexander Graf wrote:
+if (vcpu->arch.mmio_sign_extend) {
+switch (run->mmio.len) {
+#ifdef CONFIG_PPC64
+case 4:
+if (gpr& 0x8000)
+gpr |= 0xULL;
+break;
Wouldn't
gpr = (s64)(gpr << 32) >> 32;
work? Not sure if >> is guaranteed to sign extend.
Not sure either. The code as is is rather obvious imho, so I wouldn't
want to replace it with anything that's even remotely magical.
That's fair.
--
error compiling committee.c: too many arguments to function
--
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 18/18] KVM: PPC: Implement Paired Single emulation
Am 07.02.2010 um 13:50 schrieb Avi Kivity :
On 02/04/2010 05:55 PM, Alexander Graf wrote:
The one big thing about the Gekko is paired singles.
Paired singles are an extension to the instruction set, that adds
32 single
precision floating point registers (qprs), some SPRs to modify the
behavior
of paired singled operations and instructions to deal with qprs to
the
instruction set.
Unfortunately, it also changes semantics of existing operations
that affect
single values in FPRs. In most cases they get mirrored to the
coresponding
QPR.
Thanks to that we need to emulate all FPU operations and all the
new paired
single operations too.
In order to achieve that, we take the guest's instruction, rip out
the
parameters, put in our own and execute the very same instruction,
but also
fix up the QPR values along the way.
That way we can execute paired single FPU operations without
implementing a
soft fpu.
A little frightening. How many instructions are there? Maybe we
can just have an array of all of them followed by a return
instruction, so we don't jit code.
There's all the instructions in the list, most can have the rc
(compare) bit set to modify CC and iirc there were a couple ones with
immediate values.
But maybe you're right. I probably could just always set rc and either
ignore the result or use it. I could maybe find alternatives to
immediate using instructions. Let me check this on the bus trip back
from brussels.
static void call_fpu_inst(u32 inst, u64 *out, u64 *in1, u64 *in2,
u64 *in3,
+ u32 *cr, u32 *fpscr)
+{
+u32 cr_val = 0;
+u32 *call_stack;
+u64 inout[5] = { 0, 0, 0, 0, 0 };
+
+if (fpscr)
+inout[0] = *fpscr;
+if (in1)
+inout[1] = *in1;
+if (in2)
+inout[2] = *in2;
+if (in3)
+inout[3] = *in3;
+if (cr)
+cr_val = *cr;
+
+dprintk(KERN_INFO "FPU Emulator 0x%x ( 0x%llx, 0x%llx, 0x
%llx )", inst,
+inout[1], inout[2], inout[3]);
+
+call_stack =&kvmppc_call_stack[(smp_processor_id() * 2)];
+call_stack[0] = inst;
+/* call_stack[1] is INS_BLR */
+
Would be easier on the cache to do this per-cpu?
It is per-cpu. Or do you mean to actually use the PER_CPU definition?
Is that guaranteed to be executable?
Alex
--
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 02/18] KVM: PPC: Enable MMIO to do 64 bits, fprs and qprs
Am 07.02.2010 um 13:29 schrieb Avi Kivity :
On 02/04/2010 05:55 PM, Alexander Graf wrote:
Right now MMIO access can only happen for GPRs and is at most 32
bit wide.
That's actually enough for almost all types of hardware out there.
Unfortunately, the guest I was using used FPU writes to MMIO
regions, so
it ended up writing 64 bit MMIOs using FPRs and QPRs.
So let's add code to handle those odd cases too.
Signed-off-by: Alexander Graf
---
arch/powerpc/include/asm/kvm.h |7 +++
arch/powerpc/include/asm/kvm_ppc.h |2 +-
arch/powerpc/kvm/powerpc.c | 24 ++--
3 files changed, 30 insertions(+), 3 deletions(-)
diff --git a/arch/powerpc/include/asm/kvm.h b/arch/powerpc/include/
asm/kvm.h
index 81f3b0b..548376c 100644
--- a/arch/powerpc/include/asm/kvm.h
+++ b/arch/powerpc/include/asm/kvm.h
@@ -77,4 +77,11 @@ struct kvm_debug_exit_arch {
struct kvm_guest_debug_arch {
};
+#define REG_MASK0x001f
+#define REG_EXT_MASK0xffe0
+#define REG_GPR0x
+#define REG_FPR0x0020
+#define REG_QPR0x0040
+#define REG_FQPR0x0060
These names seem too generic to belong in asm/kvm.h - some
application could use the same names. Please add a KVM_ prefix.
Yes, will do.
Alex
--
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/18] KVM: PPC: Teach MMIO Signedness
Am 07.02.2010 um 13:32 schrieb Avi Kivity :
On 02/04/2010 05:55 PM, Alexander Graf wrote:
The guest I was trying to get to run uses the LHA and LHAU
instructions.
Those instructions basically do a load, but also sign extend the
result.
Since we need to fill our registers by hand when doing MMIO, we
also need
to sign extend manually.
This patch implements sign extended MMIO and the LHA(U) instructions.
@@ -300,6 +300,25 @@ static void kvmppc_complete_mmio_load(struct
kvm_vcpu *vcpu,
}
}
+if (vcpu->arch.mmio_sign_extend) {
+switch (run->mmio.len) {
+#ifdef CONFIG_PPC64
+case 4:
+if (gpr& 0x8000)
+gpr |= 0xULL;
+break;
Wouldn't
gpr = (s64)(gpr << 32) >> 32;
work? Not sure if >> is guaranteed to sign extend.
Not sure either. The code as is is rather obvious imho, so I wouldn't
want to replace it with anything that's even remotely magical.
Alex
--
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 00/18] KVM: PPC: Virtualize Gekko guests
Am 07.02.2010 um 13:54 schrieb Avi Kivity : On 02/04/2010 05:55 PM, Alexander Graf wrote: In an effort to get KVM on PPC more useful for other userspace users than Qemu, I figured it'd be a nice idea to implement virtualization of the Gekko CPU. The Gekko is the CPU used in the GameCube. In a slightly more modern fashion it lives on in the Wii today. Using this patch set and a modified version of Dolphin, I was able to virtualize simple GameCube demos on a 970MP system. As always, while getting this to run I stumbled across several broken parts and fixed them as they came up. So expect some bug fixes in this patch set too. This is halfway into emulation rather than virtualization. What does performance look like when running fpu intensive applications? It is for the FPU. It is not for whatever runs on the CPU. I haven't benchmarked things so far, The only two choices I have to get this running is in-kernel emulation or userspace emulation. According to how x86 deals with things I suppose full state transition to userspace and continuing emulation there isn't considered a good idea. So I went with in-kernel. I might have missed it, but I didn't see the KVM_CAP and save/ restore support for this. Ah, cap again. Right. Mind if I send an patch on top of the set? As far as save/restore goes, the ioctl to get/set fprs isn't even implemented (yet)! We're really off full state migration to/from userspace yet. Alex -- 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 00/18] KVM: PPC: Virtualize Gekko guests
On 02/04/2010 05:55 PM, Alexander Graf wrote: In an effort to get KVM on PPC more useful for other userspace users than Qemu, I figured it'd be a nice idea to implement virtualization of the Gekko CPU. The Gekko is the CPU used in the GameCube. In a slightly more modern fashion it lives on in the Wii today. Using this patch set and a modified version of Dolphin, I was able to virtualize simple GameCube demos on a 970MP system. As always, while getting this to run I stumbled across several broken parts and fixed them as they came up. So expect some bug fixes in this patch set too. This is halfway into emulation rather than virtualization. What does performance look like when running fpu intensive applications? I might have missed it, but I didn't see the KVM_CAP and save/restore support for this. -- error compiling committee.c: too many arguments to function -- 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 18/18] KVM: PPC: Implement Paired Single emulation
On 02/04/2010 05:55 PM, Alexander Graf wrote:
The one big thing about the Gekko is paired singles.
Paired singles are an extension to the instruction set, that adds 32 single
precision floating point registers (qprs), some SPRs to modify the behavior
of paired singled operations and instructions to deal with qprs to the
instruction set.
Unfortunately, it also changes semantics of existing operations that affect
single values in FPRs. In most cases they get mirrored to the coresponding
QPR.
Thanks to that we need to emulate all FPU operations and all the new paired
single operations too.
In order to achieve that, we take the guest's instruction, rip out the
parameters, put in our own and execute the very same instruction, but also
fix up the QPR values along the way.
That way we can execute paired single FPU operations without implementing a
soft fpu.
A little frightening. How many instructions are there? Maybe we can
just have an array of all of them followed by a return instruction, so
we don't jit code.
static void call_fpu_inst(u32 inst, u64 *out, u64 *in1, u64 *in2, u64 *in3,
+ u32 *cr, u32 *fpscr)
+{
+ u32 cr_val = 0;
+ u32 *call_stack;
+ u64 inout[5] = { 0, 0, 0, 0, 0 };
+
+ if (fpscr)
+ inout[0] = *fpscr;
+ if (in1)
+ inout[1] = *in1;
+ if (in2)
+ inout[2] = *in2;
+ if (in3)
+ inout[3] = *in3;
+ if (cr)
+ cr_val = *cr;
+
+ dprintk(KERN_INFO "FPU Emulator 0x%x ( 0x%llx, 0x%llx, 0x%llx )", inst,
+ inout[1], inout[2], inout[3]);
+
+ call_stack =&kvmppc_call_stack[(smp_processor_id() * 2)];
+ call_stack[0] = inst;
+ /* call_stack[1] is INS_BLR */
+
Would be easier on the cache to do this per-cpu?
--
error compiling committee.c: too many arguments to function
--
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/18] KVM: PPC: Teach MMIO Signedness
On 02/04/2010 05:55 PM, Alexander Graf wrote:
The guest I was trying to get to run uses the LHA and LHAU instructions.
Those instructions basically do a load, but also sign extend the result.
Since we need to fill our registers by hand when doing MMIO, we also need
to sign extend manually.
This patch implements sign extended MMIO and the LHA(U) instructions.
@@ -300,6 +300,25 @@ static void kvmppc_complete_mmio_load(struct kvm_vcpu
*vcpu,
}
}
+ if (vcpu->arch.mmio_sign_extend) {
+ switch (run->mmio.len) {
+#ifdef CONFIG_PPC64
+ case 4:
+ if (gpr& 0x8000)
+ gpr |= 0xULL;
+ break;
Wouldn't
gpr = (s64)(gpr << 32) >> 32;
work? Not sure if >> is guaranteed to sign extend.
--
error compiling committee.c: too many arguments to function
--
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 02/18] KVM: PPC: Enable MMIO to do 64 bits, fprs and qprs
On 02/04/2010 05:55 PM, Alexander Graf wrote:
Right now MMIO access can only happen for GPRs and is at most 32 bit wide.
That's actually enough for almost all types of hardware out there.
Unfortunately, the guest I was using used FPU writes to MMIO regions, so
it ended up writing 64 bit MMIOs using FPRs and QPRs.
So let's add code to handle those odd cases too.
Signed-off-by: Alexander Graf
---
arch/powerpc/include/asm/kvm.h |7 +++
arch/powerpc/include/asm/kvm_ppc.h |2 +-
arch/powerpc/kvm/powerpc.c | 24 ++--
3 files changed, 30 insertions(+), 3 deletions(-)
diff --git a/arch/powerpc/include/asm/kvm.h b/arch/powerpc/include/asm/kvm.h
index 81f3b0b..548376c 100644
--- a/arch/powerpc/include/asm/kvm.h
+++ b/arch/powerpc/include/asm/kvm.h
@@ -77,4 +77,11 @@ struct kvm_debug_exit_arch {
struct kvm_guest_debug_arch {
};
+#define REG_MASK 0x001f
+#define REG_EXT_MASK 0xffe0
+#define REG_GPR0x
+#define REG_FPR0x0020
+#define REG_QPR0x0040
+#define REG_FQPR 0x0060
These names seem too generic to belong in asm/kvm.h - some application
could use the same names. Please add a KVM_ prefix.
--
error compiling committee.c: too many arguments to function
--
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
