[PATCH v2 2/3] kvmppc/e500: Add PVR/PIR init for E500
commit 513579e3a391a3874c478a8493080822069976e8 change the way we emulate PVR/PIR, which left PVR/PIR uninitialized on E500, and make guest puzzled. Signed-off-by: Liu Yu --- arch/powerpc/kvm/e500.c |6 ++ 1 files changed, 6 insertions(+), 0 deletions(-) diff --git a/arch/powerpc/kvm/e500.c b/arch/powerpc/kvm/e500.c index 64949ee..efa1198 100644 --- a/arch/powerpc/kvm/e500.c +++ b/arch/powerpc/kvm/e500.c @@ -60,6 +60,12 @@ int kvmppc_core_vcpu_setup(struct kvm_vcpu *vcpu) kvmppc_e500_tlb_setup(vcpu_e500); + /* Registers init */ + vcpu->arch.pvr = mfspr(SPRN_PVR); + + /* Since booke kvm only support one core, update all vcpus' PIR to 0 */ + vcpu->vcpu_id = 0; + return 0; } -- 1.6.4 -- 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 v2 0/3] kvmppc/e500: fix breaks
These patches fix current e500 break. v2: patch 2: add comment about PIR patch 3: move tlbcfg code to init -- 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 v2 3/3] kvmppc/e500: fix tlbcfg emulation
commit 55fb1027c1cf9797dbdeab48180da530e81b1c39 doesn't update tlbcfg correctly.
Fix it and move this part to init code.
Signed-off-by: Liu Yu
---
arch/powerpc/include/asm/kvm_e500.h |2 ++
arch/powerpc/kvm/e500_emulate.c | 20 ++--
arch/powerpc/kvm/e500_tlb.c |6 ++
3 files changed, 10 insertions(+), 18 deletions(-)
diff --git a/arch/powerpc/include/asm/kvm_e500.h
b/arch/powerpc/include/asm/kvm_e500.h
index 569dfd3..7fea26f 100644
--- a/arch/powerpc/include/asm/kvm_e500.h
+++ b/arch/powerpc/include/asm/kvm_e500.h
@@ -56,6 +56,8 @@ struct kvmppc_vcpu_e500 {
u32 l1csr1;
u32 hid0;
u32 hid1;
+ u32 tlb0cfg;
+ u32 tlb1cfg;
struct kvm_vcpu vcpu;
};
diff --git a/arch/powerpc/kvm/e500_emulate.c b/arch/powerpc/kvm/e500_emulate.c
index 95f8ec8..8e3edfb 100644
--- a/arch/powerpc/kvm/e500_emulate.c
+++ b/arch/powerpc/kvm/e500_emulate.c
@@ -164,25 +164,9 @@ int kvmppc_core_emulate_mfspr(struct kvm_vcpu *vcpu, int
sprn, int rt)
kvmppc_set_gpr(vcpu, rt, vcpu_e500->mas7); break;
case SPRN_TLB0CFG:
- {
- ulong tmp = SPRN_TLB0CFG;
-
- tmp &= ~0xfffUL;
- tmp |= vcpu_e500->guest_tlb_size[0];
- kvmppc_set_gpr(vcpu, rt, tmp);
- break;
- }
-
+ kvmppc_set_gpr(vcpu, rt, vcpu_e500->tlb0cfg); break;
case SPRN_TLB1CFG:
- {
- ulong tmp = SPRN_TLB1CFG;
-
- tmp &= ~0xfffUL;
- tmp |= vcpu_e500->guest_tlb_size[1];
- kvmppc_set_gpr(vcpu, rt, tmp);
- break;
- }
-
+ kvmppc_set_gpr(vcpu, rt, vcpu_e500->tlb1cfg); break;
case SPRN_L1CSR0:
kvmppc_set_gpr(vcpu, rt, vcpu_e500->l1csr0); break;
case SPRN_L1CSR1:
diff --git a/arch/powerpc/kvm/e500_tlb.c b/arch/powerpc/kvm/e500_tlb.c
index 99a830b..7db158e 100644
--- a/arch/powerpc/kvm/e500_tlb.c
+++ b/arch/powerpc/kvm/e500_tlb.c
@@ -731,6 +731,12 @@ int kvmppc_e500_tlb_init(struct kvmppc_vcpu_e500
*vcpu_e500)
if (vcpu_e500->shadow_pages[1] == NULL)
goto err_out_page0;
+ /* Init TLB configuration register */
+ vcpu_e500->tlb0cfg = mfspr(SPRN_TLB0CFG) & ~0xfffUL;
+ vcpu_e500->tlb0cfg |= vcpu_e500->guest_tlb_size[0];
+ vcpu_e500->tlb1cfg = mfspr(SPRN_TLB1CFG) & ~0xfffUL;
+ vcpu_e500->tlb1cfg |= vcpu_e500->guest_tlb_size[1];
+
return 0;
err_out_page0:
--
1.6.4
--
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 v2 1/3] kvmppc/e500: Add register l1csr0 emulation
Latest kernel start to access l1csr0 to contron L1.
We just tell guest no operation is on going.
Signed-off-by: Liu Yu
---
arch/powerpc/include/asm/kvm_e500.h |1 +
arch/powerpc/kvm/e500_emulate.c |6 ++
2 files changed, 7 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/include/asm/kvm_e500.h
b/arch/powerpc/include/asm/kvm_e500.h
index 9d497ce..569dfd3 100644
--- a/arch/powerpc/include/asm/kvm_e500.h
+++ b/arch/powerpc/include/asm/kvm_e500.h
@@ -52,6 +52,7 @@ struct kvmppc_vcpu_e500 {
u32 mas5;
u32 mas6;
u32 mas7;
+ u32 l1csr0;
u32 l1csr1;
u32 hid0;
u32 hid1;
diff --git a/arch/powerpc/kvm/e500_emulate.c b/arch/powerpc/kvm/e500_emulate.c
index 7644f7a..95f8ec8 100644
--- a/arch/powerpc/kvm/e500_emulate.c
+++ b/arch/powerpc/kvm/e500_emulate.c
@@ -99,6 +99,10 @@ int kvmppc_core_emulate_mtspr(struct kvm_vcpu *vcpu, int
sprn, int rs)
vcpu_e500->mas6 = spr_val; break;
case SPRN_MAS7:
vcpu_e500->mas7 = spr_val; break;
+ case SPRN_L1CSR0:
+ vcpu_e500->l1csr0 = spr_val;
+ vcpu_e500->l1csr0 &= ~(L1CSR0_DCFI | L1CSR0_CLFC);
+ break;
case SPRN_L1CSR1:
vcpu_e500->l1csr1 = spr_val; break;
case SPRN_HID0:
@@ -179,6 +183,8 @@ int kvmppc_core_emulate_mfspr(struct kvm_vcpu *vcpu, int
sprn, int rt)
break;
}
+ case SPRN_L1CSR0:
+ kvmppc_set_gpr(vcpu, rt, vcpu_e500->l1csr0); break;
case SPRN_L1CSR1:
kvmppc_set_gpr(vcpu, rt, vcpu_e500->l1csr1); break;
case SPRN_HID0:
--
1.6.4
--
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] kvmppc/booke: Set ESR and DEAR when inject interrupt to guest
Old method prematurely sets ESR and DEAR.
Move this part after we decide to inject interrupt,
and make it more like hardware behave.
Signed-off-by: Liu Yu
---
arch/powerpc/kvm/booke.c | 24 ++--
arch/powerpc/kvm/emulate.c |2 --
2 files changed, 14 insertions(+), 12 deletions(-)
diff --git a/arch/powerpc/kvm/booke.c b/arch/powerpc/kvm/booke.c
index e283e44..a8ee148 100644
--- a/arch/powerpc/kvm/booke.c
+++ b/arch/powerpc/kvm/booke.c
@@ -84,7 +84,8 @@ static void kvmppc_booke_queue_irqprio(struct kvm_vcpu *vcpu,
void kvmppc_core_queue_program(struct kvm_vcpu *vcpu, ulong flags)
{
- /* BookE does flags in ESR, so ignore those we get here */
+ if (flags == SRR1_PROGTRAP)
+ vcpu->arch.fault_esr = ESR_PTR;
kvmppc_booke_queue_irqprio(vcpu, BOOKE_IRQPRIO_PROGRAM);
}
@@ -115,14 +116,19 @@ static int kvmppc_booke_irqprio_deliver(struct kvm_vcpu
*vcpu,
{
int allowed = 0;
ulong msr_mask;
+ bool update_esr = false, update_dear = false;
switch (priority) {
- case BOOKE_IRQPRIO_PROGRAM:
case BOOKE_IRQPRIO_DTLB_MISS:
- case BOOKE_IRQPRIO_ITLB_MISS:
- case BOOKE_IRQPRIO_SYSCALL:
case BOOKE_IRQPRIO_DATA_STORAGE:
+ update_dear = true;
+ /* fall through */
case BOOKE_IRQPRIO_INST_STORAGE:
+ case BOOKE_IRQPRIO_PROGRAM:
+ update_esr = true;
+ /* fall through */
+ case BOOKE_IRQPRIO_ITLB_MISS:
+ case BOOKE_IRQPRIO_SYSCALL:
case BOOKE_IRQPRIO_FP_UNAVAIL:
case BOOKE_IRQPRIO_SPE_UNAVAIL:
case BOOKE_IRQPRIO_SPE_FP_DATA:
@@ -157,6 +163,10 @@ static int kvmppc_booke_irqprio_deliver(struct kvm_vcpu
*vcpu,
vcpu->arch.srr0 = vcpu->arch.pc;
vcpu->arch.srr1 = vcpu->arch.msr;
vcpu->arch.pc = vcpu->arch.ivpr | vcpu->arch.ivor[priority];
+ if (update_esr == true)
+ vcpu->arch.esr = vcpu->arch.fault_esr;
+ if (update_dear == true)
+ vcpu->arch.dear = vcpu->arch.fault_dear;
kvmppc_set_msr(vcpu, vcpu->arch.msr & msr_mask);
clear_bit(priority, &vcpu->arch.pending_exceptions);
@@ -229,7 +239,6 @@ int kvmppc_handle_exit(struct kvm_run *run, struct kvm_vcpu
*vcpu,
if (vcpu->arch.msr & MSR_PR) {
/* Program traps generated by user-level software must
be handled
* by the guest kernel. */
- vcpu->arch.esr = vcpu->arch.fault_esr;
kvmppc_booke_queue_irqprio(vcpu, BOOKE_IRQPRIO_PROGRAM);
r = RESUME_GUEST;
kvmppc_account_exit(vcpu, USR_PR_INST);
@@ -286,15 +295,12 @@ int kvmppc_handle_exit(struct kvm_run *run, struct
kvm_vcpu *vcpu,
break;
case BOOKE_INTERRUPT_DATA_STORAGE:
- vcpu->arch.dear = vcpu->arch.fault_dear;
- vcpu->arch.esr = vcpu->arch.fault_esr;
kvmppc_booke_queue_irqprio(vcpu, BOOKE_IRQPRIO_DATA_STORAGE);
kvmppc_account_exit(vcpu, DSI_EXITS);
r = RESUME_GUEST;
break;
case BOOKE_INTERRUPT_INST_STORAGE:
- vcpu->arch.esr = vcpu->arch.fault_esr;
kvmppc_booke_queue_irqprio(vcpu, BOOKE_IRQPRIO_INST_STORAGE);
kvmppc_account_exit(vcpu, ISI_EXITS);
r = RESUME_GUEST;
@@ -317,8 +323,6 @@ int kvmppc_handle_exit(struct kvm_run *run, struct kvm_vcpu
*vcpu,
if (gtlb_index < 0) {
/* The guest didn't have a mapping for it. */
kvmppc_booke_queue_irqprio(vcpu,
BOOKE_IRQPRIO_DTLB_MISS);
- vcpu->arch.dear = vcpu->arch.fault_dear;
- vcpu->arch.esr = vcpu->arch.fault_esr;
kvmppc_mmu_dtlb_miss(vcpu);
kvmppc_account_exit(vcpu, DTLB_REAL_MISS_EXITS);
r = RESUME_GUEST;
diff --git a/arch/powerpc/kvm/emulate.c b/arch/powerpc/kvm/emulate.c
index b905623..4f6b9df 100644
--- a/arch/powerpc/kvm/emulate.c
+++ b/arch/powerpc/kvm/emulate.c
@@ -151,8 +151,6 @@ int kvmppc_emulate_instruction(struct kvm_run *run, struct
kvm_vcpu *vcpu)
case OP_TRAP:
#ifdef CONFIG_PPC64
case OP_TRAP_64:
-#else
- vcpu->arch.esr |= ESR_PTR;
#endif
kvmppc_core_queue_program(vcpu, SRR1_PROGTRAP);
advance = 0;
--
1.6.4
--
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 v2 3/3] kvmppc/e500: fix tlbcfg emulation
On 22.01.2010, at 11:50, Liu Yu wrote:
> commit 55fb1027c1cf9797dbdeab48180da530e81b1c39 doesn't update tlbcfg
> correctly.
> Fix it and move this part to init code.
>
> Signed-off-by: Liu Yu
> ---
> arch/powerpc/include/asm/kvm_e500.h |2 ++
> arch/powerpc/kvm/e500_emulate.c | 20 ++--
> arch/powerpc/kvm/e500_tlb.c |6 ++
> 3 files changed, 10 insertions(+), 18 deletions(-)
>
> diff --git a/arch/powerpc/include/asm/kvm_e500.h
> b/arch/powerpc/include/asm/kvm_e500.h
> index 569dfd3..7fea26f 100644
> --- a/arch/powerpc/include/asm/kvm_e500.h
> +++ b/arch/powerpc/include/asm/kvm_e500.h
> @@ -56,6 +56,8 @@ struct kvmppc_vcpu_e500 {
> u32 l1csr1;
> u32 hid0;
> u32 hid1;
> + u32 tlb0cfg;
> + u32 tlb1cfg;
>
> struct kvm_vcpu vcpu;
> };
> diff --git a/arch/powerpc/kvm/e500_emulate.c b/arch/powerpc/kvm/e500_emulate.c
> index 95f8ec8..8e3edfb 100644
> --- a/arch/powerpc/kvm/e500_emulate.c
> +++ b/arch/powerpc/kvm/e500_emulate.c
> @@ -164,25 +164,9 @@ int kvmppc_core_emulate_mfspr(struct kvm_vcpu *vcpu, int
> sprn, int rt)
> kvmppc_set_gpr(vcpu, rt, vcpu_e500->mas7); break;
>
> case SPRN_TLB0CFG:
> - {
> - ulong tmp = SPRN_TLB0CFG;
> -
> - tmp &= ~0xfffUL;
> - tmp |= vcpu_e500->guest_tlb_size[0];
> - kvmppc_set_gpr(vcpu, rt, tmp);
> - break;
> - }
> -
> + kvmppc_set_gpr(vcpu, rt, vcpu_e500->tlb0cfg); break;
So before the guest couldn't change the guest TLB size and now it can? Is that
on purpose? Mind to explain why the old code was there?
The rest looks good.
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 v2 2/3] kvmppc/e500: Add PVR/PIR init for E500
On 22.01.2010, at 11:50, Liu Yu wrote: > commit 513579e3a391a3874c478a8493080822069976e8 change the way > we emulate PVR/PIR, > which left PVR/PIR uninitialized on E500, and make guest puzzled. > > Signed-off-by: Liu Yu Acked-by: Alexander Graf -- 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 v2 1/3] kvmppc/e500: Add register l1csr0 emulation
On 22.01.2010, at 11:50, Liu Yu wrote: > Latest kernel start to access l1csr0 to contron L1. control? :) > We just tell guest no operation is on going. > > Signed-off-by: Liu Yu Acked-by: Alexander Graf -- 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 v2 3/3] kvmppc/e500: fix tlbcfg emulation
> -Original Message-
> From: Alexander Graf [mailto:ag...@suse.de]
> Sent: Friday, January 22, 2010 7:05 PM
> To: Liu Yu-B13201
> Cc: kvm-ppc@vger.kernel.org; k...@vger.kernel.org
> Subject: Re: [PATCH v2 3/3] kvmppc/e500: fix tlbcfg emulation
>
>
> On 22.01.2010, at 11:50, Liu Yu wrote:
>
> > commit 55fb1027c1cf9797dbdeab48180da530e81b1c39 doesn't
> update tlbcfg correctly.
> > Fix it and move this part to init code.
> >
> > Signed-off-by: Liu Yu
> > ---
> > arch/powerpc/include/asm/kvm_e500.h |2 ++
> > arch/powerpc/kvm/e500_emulate.c | 20 ++--
> > arch/powerpc/kvm/e500_tlb.c |6 ++
> > 3 files changed, 10 insertions(+), 18 deletions(-)
> >
> > diff --git a/arch/powerpc/include/asm/kvm_e500.h
> b/arch/powerpc/include/asm/kvm_e500.h
> > index 569dfd3..7fea26f 100644
> > --- a/arch/powerpc/include/asm/kvm_e500.h
> > +++ b/arch/powerpc/include/asm/kvm_e500.h
> > @@ -56,6 +56,8 @@ struct kvmppc_vcpu_e500 {
> > u32 l1csr1;
> > u32 hid0;
> > u32 hid1;
> > + u32 tlb0cfg;
> > + u32 tlb1cfg;
> >
> > struct kvm_vcpu vcpu;
> > };
> > diff --git a/arch/powerpc/kvm/e500_emulate.c
> b/arch/powerpc/kvm/e500_emulate.c
> > index 95f8ec8..8e3edfb 100644
> > --- a/arch/powerpc/kvm/e500_emulate.c
> > +++ b/arch/powerpc/kvm/e500_emulate.c
> > @@ -164,25 +164,9 @@ int kvmppc_core_emulate_mfspr(struct
> kvm_vcpu *vcpu, int sprn, int rt)
> > kvmppc_set_gpr(vcpu, rt, vcpu_e500->mas7); break;
> >
> > case SPRN_TLB0CFG:
> > - {
> > - ulong tmp = SPRN_TLB0CFG;
> > -
> > - tmp &= ~0xfffUL;
> > - tmp |= vcpu_e500->guest_tlb_size[0];
> > - kvmppc_set_gpr(vcpu, rt, tmp);
> > - break;
> > - }
> > -
> > + kvmppc_set_gpr(vcpu, rt, vcpu_e500->tlb0cfg); break;
>
> So before the guest couldn't change the guest TLB size and
> now it can? Is that on purpose? Mind to explain why the old
> code was there?
>
What? The register is readonly.
I was thinking we could change guest TLB size online.
But I don't think guest kernel would like that.
--
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] kvmppc/booke: Set ESR and DEAR when inject interrupt to guest
On 22.01.2010, at 11:54, Liu Yu wrote:
> Old method prematurely sets ESR and DEAR.
> Move this part after we decide to inject interrupt,
> and make it more like hardware behave.
>
> Signed-off-by: Liu Yu
> ---
> arch/powerpc/kvm/booke.c | 24 ++--
> arch/powerpc/kvm/emulate.c |2 --
> 2 files changed, 14 insertions(+), 12 deletions(-)
>
> diff --git a/arch/powerpc/kvm/booke.c b/arch/powerpc/kvm/booke.c
> index e283e44..a8ee148 100644
> --- a/arch/powerpc/kvm/booke.c
> +++ b/arch/powerpc/kvm/booke.c
> @@ -84,7 +84,8 @@ static void kvmppc_booke_queue_irqprio(struct kvm_vcpu
> *vcpu,
>
> void kvmppc_core_queue_program(struct kvm_vcpu *vcpu, ulong flags)
> {
> - /* BookE does flags in ESR, so ignore those we get here */
> + if (flags == SRR1_PROGTRAP)
> + vcpu->arch.fault_esr = ESR_PTR;
This looks odd. I was more thinking of "flags" being ESR in this context. So
you'd save off flags to a field in the vcpu here and restore it later when the
fault actually gets injected.
> kvmppc_booke_queue_irqprio(vcpu, BOOKE_IRQPRIO_PROGRAM);
> }
>
> @@ -115,14 +116,19 @@ static int kvmppc_booke_irqprio_deliver(struct kvm_vcpu
> *vcpu,
> {
> int allowed = 0;
> ulong msr_mask;
> + bool update_esr = false, update_dear = false;
>
> switch (priority) {
> - case BOOKE_IRQPRIO_PROGRAM:
> case BOOKE_IRQPRIO_DTLB_MISS:
> - case BOOKE_IRQPRIO_ITLB_MISS:
> - case BOOKE_IRQPRIO_SYSCALL:
Is this correct? Was the previous order wrong according to the spec?
> case BOOKE_IRQPRIO_DATA_STORAGE:
> + update_dear = true;
> + /* fall through */
> case BOOKE_IRQPRIO_INST_STORAGE:
> + case BOOKE_IRQPRIO_PROGRAM:
> + update_esr = true;
> + /* fall through */
> + case BOOKE_IRQPRIO_ITLB_MISS:
> + case BOOKE_IRQPRIO_SYSCALL:
> case BOOKE_IRQPRIO_FP_UNAVAIL:
> case BOOKE_IRQPRIO_SPE_UNAVAIL:
> case BOOKE_IRQPRIO_SPE_FP_DATA:
> @@ -157,6 +163,10 @@ static int kvmppc_booke_irqprio_deliver(struct kvm_vcpu
> *vcpu,
> vcpu->arch.srr0 = vcpu->arch.pc;
> vcpu->arch.srr1 = vcpu->arch.msr;
> vcpu->arch.pc = vcpu->arch.ivpr | vcpu->arch.ivor[priority];
> + if (update_esr == true)
> + vcpu->arch.esr = vcpu->arch.fault_esr;
I'd rather like to see new fields used for that.
> + if (update_dear == true)
> + vcpu->arch.dear = vcpu->arch.fault_dear;
same here
> kvmppc_set_msr(vcpu, vcpu->arch.msr & msr_mask);
>
> clear_bit(priority, &vcpu->arch.pending_exceptions);
> @@ -229,7 +239,6 @@ int kvmppc_handle_exit(struct kvm_run *run, struct
> kvm_vcpu *vcpu,
> if (vcpu->arch.msr & MSR_PR) {
> /* Program traps generated by user-level software must
> be handled
>* by the guest kernel. */
> - vcpu->arch.esr = vcpu->arch.fault_esr;
> kvmppc_booke_queue_irqprio(vcpu, BOOKE_IRQPRIO_PROGRAM);
> r = RESUME_GUEST;
> kvmppc_account_exit(vcpu, USR_PR_INST);
> @@ -286,15 +295,12 @@ int kvmppc_handle_exit(struct kvm_run *run, struct
> kvm_vcpu *vcpu,
> break;
>
> case BOOKE_INTERRUPT_DATA_STORAGE:
> - vcpu->arch.dear = vcpu->arch.fault_dear;
> - vcpu->arch.esr = vcpu->arch.fault_esr;
> kvmppc_booke_queue_irqprio(vcpu, BOOKE_IRQPRIO_DATA_STORAGE);
kvmppc_booke_queue_data_storage(vcpu, vcpu->arch.fault_esr,
vcpu->arch.fault_dear);
> kvmppc_account_exit(vcpu, DSI_EXITS);
> r = RESUME_GUEST;
> break;
>
> case BOOKE_INTERRUPT_INST_STORAGE:
> - vcpu->arch.esr = vcpu->arch.fault_esr;
> kvmppc_booke_queue_irqprio(vcpu, BOOKE_IRQPRIO_INST_STORAGE);
kvmppc_booke_queue_inst_storage(vcpu, vcpu->arch.fault_esr);
> kvmppc_account_exit(vcpu, ISI_EXITS);
> r = RESUME_GUEST;
> @@ -317,8 +323,6 @@ int kvmppc_handle_exit(struct kvm_run *run, struct
> kvm_vcpu *vcpu,
> if (gtlb_index < 0) {
> /* The guest didn't have a mapping for it. */
> kvmppc_booke_queue_irqprio(vcpu,
> BOOKE_IRQPRIO_DTLB_MISS);
see above
> - vcpu->arch.dear = vcpu->arch.fault_dear;
> - vcpu->arch.esr = vcpu->arch.fault_esr;
> kvmppc_mmu_dtlb_miss(vcpu);
> kvmppc_account_exit(vcpu, DTLB_REAL_MISS_EXITS);
> r = RESUME_GUEST;
> diff --git a/arch/powerpc/kvm/emulate.c b/arch/powerpc/kvm/emulate.c
> index b905623..4f6b9df 100644
> --- a/arch/powerpc/kvm/emulate.c
> +++ b/arch/powerpc/kvm/emulate.c
> @@ -151,8 +151,6 @@ int kvmppc_emulate_instruction(struct kvm_run *run,
> struct kvm_vcpu *vcpu)
> case OP_TRAP:
> #ifdef CONFIG
Re: [PATCH v2 3/3] kvmppc/e500: fix tlbcfg emulation
On 22.01.2010, at 12:12, Liu Yu-B13201 wrote:
>
>
>> -Original Message-
>> From: Alexander Graf [mailto:ag...@suse.de]
>> Sent: Friday, January 22, 2010 7:05 PM
>> To: Liu Yu-B13201
>> Cc: kvm-ppc@vger.kernel.org; k...@vger.kernel.org
>> Subject: Re: [PATCH v2 3/3] kvmppc/e500: fix tlbcfg emulation
>>
>>
>> On 22.01.2010, at 11:50, Liu Yu wrote:
>>
>>> commit 55fb1027c1cf9797dbdeab48180da530e81b1c39 doesn't
>> update tlbcfg correctly.
>>> Fix it and move this part to init code.
>>>
>>> Signed-off-by: Liu Yu
>>> ---
>>> arch/powerpc/include/asm/kvm_e500.h |2 ++
>>> arch/powerpc/kvm/e500_emulate.c | 20 ++--
>>> arch/powerpc/kvm/e500_tlb.c |6 ++
>>> 3 files changed, 10 insertions(+), 18 deletions(-)
>>>
>>> diff --git a/arch/powerpc/include/asm/kvm_e500.h
>> b/arch/powerpc/include/asm/kvm_e500.h
>>> index 569dfd3..7fea26f 100644
>>> --- a/arch/powerpc/include/asm/kvm_e500.h
>>> +++ b/arch/powerpc/include/asm/kvm_e500.h
>>> @@ -56,6 +56,8 @@ struct kvmppc_vcpu_e500 {
>>> u32 l1csr1;
>>> u32 hid0;
>>> u32 hid1;
>>> + u32 tlb0cfg;
>>> + u32 tlb1cfg;
>>>
>>> struct kvm_vcpu vcpu;
>>> };
>>> diff --git a/arch/powerpc/kvm/e500_emulate.c
>> b/arch/powerpc/kvm/e500_emulate.c
>>> index 95f8ec8..8e3edfb 100644
>>> --- a/arch/powerpc/kvm/e500_emulate.c
>>> +++ b/arch/powerpc/kvm/e500_emulate.c
>>> @@ -164,25 +164,9 @@ int kvmppc_core_emulate_mfspr(struct
>> kvm_vcpu *vcpu, int sprn, int rt)
>>> kvmppc_set_gpr(vcpu, rt, vcpu_e500->mas7); break;
>>>
>>> case SPRN_TLB0CFG:
>>> - {
>>> - ulong tmp = SPRN_TLB0CFG;
>>> -
>>> - tmp &= ~0xfffUL;
>>> - tmp |= vcpu_e500->guest_tlb_size[0];
>>> - kvmppc_set_gpr(vcpu, rt, tmp);
>>> - break;
>>> - }
>>> -
>>> + kvmppc_set_gpr(vcpu, rt, vcpu_e500->tlb0cfg); break;
>>
>> So before the guest couldn't change the guest TLB size and
>> now it can? Is that on purpose? Mind to explain why the old
>> code was there?
>>
>
> What? The register is readonly.
> I was thinking we could change guest TLB size online.
> But I don't think guest kernel would like that.
Oh, I see. Mind to resend this patch with a patch description that explains
that? :-)
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] kvmppc/booke: Set ESR and DEAR when inject interrupt to guest
> -Original Message-
> From: kvm-ppc-ow...@vger.kernel.org
> [mailto:kvm-ppc-ow...@vger.kernel.org] On Behalf Of Alexander Graf
> Sent: Friday, January 22, 2010 7:13 PM
> To: Liu Yu-B13201
> Cc: hol...@penguinppc.org; kvm-ppc@vger.kernel.org;
> k...@vger.kernel.org
> Subject: Re: [PATCH] kvmppc/booke: Set ESR and DEAR when
> inject interrupt to guest
>
>
> On 22.01.2010, at 11:54, Liu Yu wrote:
>
> > Old method prematurely sets ESR and DEAR.
> > Move this part after we decide to inject interrupt,
> > and make it more like hardware behave.
> >
> > Signed-off-by: Liu Yu
> > ---
> > arch/powerpc/kvm/booke.c | 24 ++--
> > arch/powerpc/kvm/emulate.c |2 --
> > 2 files changed, 14 insertions(+), 12 deletions(-)
> >
> > diff --git a/arch/powerpc/kvm/booke.c b/arch/powerpc/kvm/booke.c
> > index e283e44..a8ee148 100644
> > --- a/arch/powerpc/kvm/booke.c
> > +++ b/arch/powerpc/kvm/booke.c
> > @@ -84,7 +84,8 @@ static void
> kvmppc_booke_queue_irqprio(struct kvm_vcpu *vcpu,
> >
> > void kvmppc_core_queue_program(struct kvm_vcpu *vcpu, ulong flags)
> > {
> > - /* BookE does flags in ESR, so ignore those we get here */
> > + if (flags == SRR1_PROGTRAP)
> > + vcpu->arch.fault_esr = ESR_PTR;
>
> This looks odd. I was more thinking of "flags" being ESR in
> this context. So you'd save off flags to a field in the vcpu
> here and restore it later when the fault actually gets injected.
See the end.
>
> > kvmppc_booke_queue_irqprio(vcpu, BOOKE_IRQPRIO_PROGRAM);
> > }
> >
> > @@ -115,14 +116,19 @@ static int
> kvmppc_booke_irqprio_deliver(struct kvm_vcpu *vcpu,
> > {
> > int allowed = 0;
> > ulong msr_mask;
> > + bool update_esr = false, update_dear = false;
> >
> > switch (priority) {
> > - case BOOKE_IRQPRIO_PROGRAM:
> > case BOOKE_IRQPRIO_DTLB_MISS:
> > - case BOOKE_IRQPRIO_ITLB_MISS:
> > - case BOOKE_IRQPRIO_SYSCALL:
>
> Is this correct? Was the previous order wrong according to the spec?
what order? just make switch items share the code.
>
> > case BOOKE_IRQPRIO_DATA_STORAGE:
> > + update_dear = true;
> > + /* fall through */
> > case BOOKE_IRQPRIO_INST_STORAGE:
> > + case BOOKE_IRQPRIO_PROGRAM:
> > + update_esr = true;
> > + /* fall through */
> > + case BOOKE_IRQPRIO_ITLB_MISS:
> > + case BOOKE_IRQPRIO_SYSCALL:
> > case BOOKE_IRQPRIO_FP_UNAVAIL:
> > case BOOKE_IRQPRIO_SPE_UNAVAIL:
> > case BOOKE_IRQPRIO_SPE_FP_DATA:
> > @@ -157,6 +163,10 @@ static int
> kvmppc_booke_irqprio_deliver(struct kvm_vcpu *vcpu,
> > vcpu->arch.srr0 = vcpu->arch.pc;
> > vcpu->arch.srr1 = vcpu->arch.msr;
> > vcpu->arch.pc = vcpu->arch.ivpr |
> vcpu->arch.ivor[priority];
> > + if (update_esr == true)
> > + vcpu->arch.esr = vcpu->arch.fault_esr;
>
> I'd rather like to see new fields used for that.
> > @@ -286,15 +295,12 @@ int kvmppc_handle_exit(struct kvm_run
> *run, struct kvm_vcpu *vcpu,
> > break;
> >
> > case BOOKE_INTERRUPT_DATA_STORAGE:
> > - vcpu->arch.dear = vcpu->arch.fault_dear;
> > - vcpu->arch.esr = vcpu->arch.fault_esr;
> > kvmppc_booke_queue_irqprio(vcpu,
> BOOKE_IRQPRIO_DATA_STORAGE);
>
> kvmppc_booke_queue_data_storage(vcpu, vcpu->arch.fault_esr,
> vcpu->arch.fault_dear);
>
> > kvmppc_account_exit(vcpu, DSI_EXITS);
> > r = RESUME_GUEST;
> > break;
> >
> > case BOOKE_INTERRUPT_INST_STORAGE:
> > - vcpu->arch.esr = vcpu->arch.fault_esr;
> > kvmppc_booke_queue_irqprio(vcpu,
> BOOKE_IRQPRIO_INST_STORAGE);
>
> kvmppc_booke_queue_inst_storage(vcpu, vcpu->arch.fault_esr);
>
Not sure if this is redundant, as we already have fault_esr.
Or should we ignore what hareware is and create a new esr to guest?
>
> > - vcpu->arch.dear = vcpu->arch.fault_dear;
> > - vcpu->arch.esr = vcpu->arch.fault_esr;
> > kvmppc_mmu_dtlb_miss(vcpu);
> > kvmppc_account_exit(vcpu, DTLB_REAL_MISS_EXITS);
> > r = RESUME_GUEST;
> > diff --git a/arch/powerpc/kvm/emulate.c b/arch/powerpc/kvm/emulate.c
> > index b905623..4f6b9df 100644
> > --- a/arch/powerpc/kvm/emulate.c
> > +++ b/arch/powerpc/kvm/emulate.c
> > @@ -151,8 +151,6 @@ int kvmppc_emulate_instruction(struct
> kvm_run *run, struct kvm_vcpu *vcpu)
> > case OP_TRAP:
> > #ifdef CONFIG_PPC64
> > case OP_TRAP_64:
> > -#else
> > - vcpu->arch.esr |= ESR_PTR;
> > #endif
> > kvmppc_core_queue_program(vcpu, SRR1_PROGTRAP);
>
> kvmppc_core_queue_program(vcpu, vcpu->arch.esr | ESR_PTR);
>
This breaks book3s code.
--
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] kvmppc/booke: Set ESR and DEAR when inject interrupt to guest
On 22.01.2010, at 12:27, Liu Yu-B13201 wrote:
>
>
>> -Original Message-
>> From: kvm-ppc-ow...@vger.kernel.org
>> [mailto:kvm-ppc-ow...@vger.kernel.org] On Behalf Of Alexander Graf
>> Sent: Friday, January 22, 2010 7:13 PM
>> To: Liu Yu-B13201
>> Cc: hol...@penguinppc.org; kvm-ppc@vger.kernel.org;
>> k...@vger.kernel.org
>> Subject: Re: [PATCH] kvmppc/booke: Set ESR and DEAR when
>> inject interrupt to guest
>>
>>
>> On 22.01.2010, at 11:54, Liu Yu wrote:
>>
>>> Old method prematurely sets ESR and DEAR.
>>> Move this part after we decide to inject interrupt,
>>> and make it more like hardware behave.
>>>
>>> Signed-off-by: Liu Yu
>>> ---
>>> arch/powerpc/kvm/booke.c | 24 ++--
>>> arch/powerpc/kvm/emulate.c |2 --
>>> 2 files changed, 14 insertions(+), 12 deletions(-)
>>>
>>> diff --git a/arch/powerpc/kvm/booke.c b/arch/powerpc/kvm/booke.c
>>> index e283e44..a8ee148 100644
>>> --- a/arch/powerpc/kvm/booke.c
>>> +++ b/arch/powerpc/kvm/booke.c
>>> @@ -84,7 +84,8 @@ static void
>> kvmppc_booke_queue_irqprio(struct kvm_vcpu *vcpu,
>>>
>>> void kvmppc_core_queue_program(struct kvm_vcpu *vcpu, ulong flags)
>>> {
>>> - /* BookE does flags in ESR, so ignore those we get here */
>>> + if (flags == SRR1_PROGTRAP)
>>> + vcpu->arch.fault_esr = ESR_PTR;
>>
>> This looks odd. I was more thinking of "flags" being ESR in
>> this context. So you'd save off flags to a field in the vcpu
>> here and restore it later when the fault actually gets injected.
>
> See the end.
>
>>
>>> kvmppc_booke_queue_irqprio(vcpu, BOOKE_IRQPRIO_PROGRAM);
>>> }
>>>
>>> @@ -115,14 +116,19 @@ static int
>> kvmppc_booke_irqprio_deliver(struct kvm_vcpu *vcpu,
>>> {
>>> int allowed = 0;
>>> ulong msr_mask;
>>> + bool update_esr = false, update_dear = false;
>>>
>>> switch (priority) {
>>> - case BOOKE_IRQPRIO_PROGRAM:
>>> case BOOKE_IRQPRIO_DTLB_MISS:
>>> - case BOOKE_IRQPRIO_ITLB_MISS:
>>> - case BOOKE_IRQPRIO_SYSCALL:
>>
>> Is this correct? Was the previous order wrong according to the spec?
>
> what order? just make switch items share the code.
Yikes. Yes. My fault.
>
>>
>>> case BOOKE_IRQPRIO_DATA_STORAGE:
>>> + update_dear = true;
>>> + /* fall through */
>>> case BOOKE_IRQPRIO_INST_STORAGE:
>>> + case BOOKE_IRQPRIO_PROGRAM:
>>> + update_esr = true;
>>> + /* fall through */
>>> + case BOOKE_IRQPRIO_ITLB_MISS:
>>> + case BOOKE_IRQPRIO_SYSCALL:
>>> case BOOKE_IRQPRIO_FP_UNAVAIL:
>>> case BOOKE_IRQPRIO_SPE_UNAVAIL:
>>> case BOOKE_IRQPRIO_SPE_FP_DATA:
>>> @@ -157,6 +163,10 @@ static int
>> kvmppc_booke_irqprio_deliver(struct kvm_vcpu *vcpu,
>>> vcpu->arch.srr0 = vcpu->arch.pc;
>>> vcpu->arch.srr1 = vcpu->arch.msr;
>>> vcpu->arch.pc = vcpu->arch.ivpr |
>> vcpu->arch.ivor[priority];
>>> + if (update_esr == true)
>>> + vcpu->arch.esr = vcpu->arch.fault_esr;
>>
>> I'd rather like to see new fields used for that.
>>> @@ -286,15 +295,12 @@ int kvmppc_handle_exit(struct kvm_run
>> *run, struct kvm_vcpu *vcpu,
>>> break;
>>>
>>> case BOOKE_INTERRUPT_DATA_STORAGE:
>>> - vcpu->arch.dear = vcpu->arch.fault_dear;
>>> - vcpu->arch.esr = vcpu->arch.fault_esr;
>>> kvmppc_booke_queue_irqprio(vcpu,
>> BOOKE_IRQPRIO_DATA_STORAGE);
>>
>> kvmppc_booke_queue_data_storage(vcpu, vcpu->arch.fault_esr,
>> vcpu->arch.fault_dear);
>>
>>> kvmppc_account_exit(vcpu, DSI_EXITS);
>>> r = RESUME_GUEST;
>>> break;
>>>
>>> case BOOKE_INTERRUPT_INST_STORAGE:
>>> - vcpu->arch.esr = vcpu->arch.fault_esr;
>>> kvmppc_booke_queue_irqprio(vcpu,
>> BOOKE_IRQPRIO_INST_STORAGE);
>>
>> kvmppc_booke_queue_inst_storage(vcpu, vcpu->arch.fault_esr);
>>
>
> Not sure if this is redundant, as we already have fault_esr.
> Or should we ignore what hareware is and create a new esr to guest?
On Book3S I take the SRR1 we get from the host as "inspiration" of what to pass
to the guest as SRR1. I think we should definitely be able to inject a fault
that we didn't get in that exact form from the exit path.
I'm also not sure if something could clobber fault_esr if another interrupt
takes precedence. Say a #MC.
>
>>
>>> - vcpu->arch.dear = vcpu->arch.fault_dear;
>>> - vcpu->arch.esr = vcpu->arch.fault_esr;
>>> kvmppc_mmu_dtlb_miss(vcpu);
>>> kvmppc_account_exit(vcpu, DTLB_REAL_MISS_EXITS);
>>> r = RESUME_GUEST;
>>> diff --git a/arch/powerpc/kvm/emulate.c b/arch/powerpc/kvm/emulate.c
>>> index b905623..4f6b9df 100644
>>> --- a/arch/powerpc/kvm/emulate.c
>>> +++ b/arch/powerpc/kvm/emulate.c
>>> @@ -151,8 +151,6 @@ int kvmppc_emulate_instruction(struct
>> kvm_run *run, struct kvm_vcpu *vcpu)
>>> case OP_TRAP:
>>> #ifdef CONFIG_PPC64
>>> case OP_TRAP_
[PATCH v3 3/3] kvmppc/e500: fix tlbcfg emulation
commit 55fb1027c1cf9797dbdeab48180da530e81b1c39 doesn't update tlbcfg correctly.
Fix it.
And since guest OS likes 'fixed' hardware,
initialize tlbcfg everytime when guest access is useless.
So move this part to init code.
Signed-off-by: Liu Yu
---
v3:
change the commit message.
arch/powerpc/include/asm/kvm_e500.h |2 ++
arch/powerpc/kvm/e500_emulate.c | 20 ++--
arch/powerpc/kvm/e500_tlb.c |6 ++
3 files changed, 10 insertions(+), 18 deletions(-)
diff --git a/arch/powerpc/include/asm/kvm_e500.h
b/arch/powerpc/include/asm/kvm_e500.h
index 569dfd3..7fea26f 100644
--- a/arch/powerpc/include/asm/kvm_e500.h
+++ b/arch/powerpc/include/asm/kvm_e500.h
@@ -56,6 +56,8 @@ struct kvmppc_vcpu_e500 {
u32 l1csr1;
u32 hid0;
u32 hid1;
+ u32 tlb0cfg;
+ u32 tlb1cfg;
struct kvm_vcpu vcpu;
};
diff --git a/arch/powerpc/kvm/e500_emulate.c b/arch/powerpc/kvm/e500_emulate.c
index 95f8ec8..8e3edfb 100644
--- a/arch/powerpc/kvm/e500_emulate.c
+++ b/arch/powerpc/kvm/e500_emulate.c
@@ -164,25 +164,9 @@ int kvmppc_core_emulate_mfspr(struct kvm_vcpu *vcpu, int
sprn, int rt)
kvmppc_set_gpr(vcpu, rt, vcpu_e500->mas7); break;
case SPRN_TLB0CFG:
- {
- ulong tmp = SPRN_TLB0CFG;
-
- tmp &= ~0xfffUL;
- tmp |= vcpu_e500->guest_tlb_size[0];
- kvmppc_set_gpr(vcpu, rt, tmp);
- break;
- }
-
+ kvmppc_set_gpr(vcpu, rt, vcpu_e500->tlb0cfg); break;
case SPRN_TLB1CFG:
- {
- ulong tmp = SPRN_TLB1CFG;
-
- tmp &= ~0xfffUL;
- tmp |= vcpu_e500->guest_tlb_size[1];
- kvmppc_set_gpr(vcpu, rt, tmp);
- break;
- }
-
+ kvmppc_set_gpr(vcpu, rt, vcpu_e500->tlb1cfg); break;
case SPRN_L1CSR0:
kvmppc_set_gpr(vcpu, rt, vcpu_e500->l1csr0); break;
case SPRN_L1CSR1:
diff --git a/arch/powerpc/kvm/e500_tlb.c b/arch/powerpc/kvm/e500_tlb.c
index 99a830b..7db158e 100644
--- a/arch/powerpc/kvm/e500_tlb.c
+++ b/arch/powerpc/kvm/e500_tlb.c
@@ -731,6 +731,12 @@ int kvmppc_e500_tlb_init(struct kvmppc_vcpu_e500
*vcpu_e500)
if (vcpu_e500->shadow_pages[1] == NULL)
goto err_out_page0;
+ /* Init TLB configuration register */
+ vcpu_e500->tlb0cfg = mfspr(SPRN_TLB0CFG) & ~0xfffUL;
+ vcpu_e500->tlb0cfg |= vcpu_e500->guest_tlb_size[0];
+ vcpu_e500->tlb1cfg = mfspr(SPRN_TLB1CFG) & ~0xfffUL;
+ vcpu_e500->tlb1cfg |= vcpu_e500->guest_tlb_size[1];
+
return 0;
err_out_page0:
--
1.6.4
--
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 v3 3/3] kvmppc/e500: fix tlbcfg emulation
On 22.01.2010, at 12:36, Liu Yu wrote: > commit 55fb1027c1cf9797dbdeab48180da530e81b1c39 doesn't update tlbcfg > correctly. > Fix it. > > And since guest OS likes 'fixed' hardware, > initialize tlbcfg everytime when guest access is useless. > So move this part to init code. > > Signed-off-by: Liu Yu Acked-by: Alexander Graf -- 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
KVM on 440GP
I'm playing around with KVM on an ebony board (440GP), just trying to
get it to work, really. I followed the instructions at
http://www.linux-kvm.org/page/PowerPC and I used the 2.6.33 branch of
the kvm kernel repository. When I try to run kvm, qemu appears to abort
and actually logs me off.
Doing a little debugging, I found that qemu_memalign() is calling abort
because posix_memalign() is failing. I haven't done any more debugging
than that.
Since I already had to fix a kernel issue to get it the kernel code to
initialize since the platform was reported as ppc440gp, not ppc440, I'm
wondering how hard it's going to be to get this working. Does anyone
have this working at all? Should I back up to a previous version? Any
help would be appreciated.
Thanks,
-corey
Here's the change I made to get kvm in the kernel to initialize:
Index: kvm/arch/powerpc/kvm/44x.c
===
--- kvm.orig/arch/powerpc/kvm/44x.c
+++ kvm/arch/powerpc/kvm/44x.c
@@ -42,7 +42,7 @@ int kvmppc_core_check_processor_compat(v
{
int r;
- if (strcmp(cur_cpu_spec->platform, "ppc440") == 0)
+ if (strncmp(cur_cpu_spec->platform, "ppc440", 6) == 0)
r = 0;
else
r = -ENOTSUPP;
--
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: KVM on 440GP
Corey Minyard wrote:
I'm playing around with KVM on an ebony board (440GP), just trying to
get it to work, really. I followed the instructions at
http://www.linux-kvm.org/page/PowerPC and I used the 2.6.33 branch of
the kvm kernel repository. When I try to run kvm, qemu appears to
abort and actually logs me off.
Doing a little debugging, I found that qemu_memalign() is calling
abort because posix_memalign() is failing. I haven't done any more
debugging than that.
Well, I discovered that the default memory is 128M, and that's too much
memory for a VM running on a machine with 128M. I fixed that problem,
and now it's doing something, though no console so not sure what.
I guess my questions below and the patch still apply.
-corey
Since I already had to fix a kernel issue to get it the kernel code to
initialize since the platform was reported as ppc440gp, not ppc440,
I'm wondering how hard it's going to be to get this working. Does
anyone have this working at all? Should I back up to a previous
version? Any help would be appreciated.
Thanks,
-corey
Here's the change I made to get kvm in the kernel to initialize:
Index: kvm/arch/powerpc/kvm/44x.c
===
--- kvm.orig/arch/powerpc/kvm/44x.c
+++ kvm/arch/powerpc/kvm/44x.c
@@ -42,7 +42,7 @@ int kvmppc_core_check_processor_compat(v
{
int r;
- if (strcmp(cur_cpu_spec->platform, "ppc440") == 0)
+ if (strncmp(cur_cpu_spec->platform, "ppc440", 6) == 0)
r = 0;
else
r = -ENOTSUPP;
--
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: KVM on 440GP
On Fri, Jan 22, 2010 at 7:27 AM, Corey Minyard wrote:
> Corey Minyard wrote:
>>
>> I'm playing around with KVM on an ebony board (440GP), just trying to get
>> it to work, really. I followed the instructions at
>> http://www.linux-kvm.org/page/PowerPC and I used the 2.6.33 branch of the
>> kvm kernel repository. When I try to run kvm, qemu appears to abort and
>> actually logs me off.
>>
>> Doing a little debugging, I found that qemu_memalign() is calling abort
>> because posix_memalign() is failing. I haven't done any more debugging than
>> that.
>
> Well, I discovered that the default memory is 128M, and that's too much
> memory for a VM running on a machine with 128M. I fixed that problem, and
> now it's doing something, though no console so not sure what.
>
> I guess my questions below and the patch still apply.
>
> -corey
>
>>
>> Since I already had to fix a kernel issue to get it the kernel code to
>> initialize since the platform was reported as ppc440gp, not ppc440, I'm
>> wondering how hard it's going to be to get this working. Does anyone have
>> this working at all? Should I back up to a previous version? Any help
>> would be appreciated.
>>
>> Thanks,
>>
>> -corey
>>
>> Here's the change I made to get kvm in the kernel to initialize:
>>
>>
>> Index: kvm/arch/powerpc/kvm/44x.c
>> ===
>> --- kvm.orig/arch/powerpc/kvm/44x.c
>> +++ kvm/arch/powerpc/kvm/44x.c
>> @@ -42,7 +42,7 @@ int kvmppc_core_check_processor_compat(v
>> {
>> int r;
>>
>> - if (strcmp(cur_cpu_spec->platform, "ppc440") == 0)
>> + if (strncmp(cur_cpu_spec->platform, "ppc440", 6) == 0)
>> r = 0;
>> else
>> r = -ENOTSUPP;
>>
>>
Thanks! The patch looks good to me. It's unfortunate that 440GP is
reported is "ppc440gp", while every other 440 variant is reported is
"ppc440", but that's just how it goes I guess. It shouldn't be too
difficult to get things working, since the cores are more or less the
same. There has been a little accidental build breakage introduced in
the 440 code recently (work to support the "Book S" KVM port), but
it's all been simple stuff.
As for console, you probably want to use qemu's "-nographic" or at
least "-serial stdio" options.
-Hollis
--
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: KVM on 440GP
Hollis Blanchard wrote: Thanks! The patch looks good to me. It's unfortunate that 440GP is reported is "ppc440gp", while every other 440 variant is reported is "ppc440", but that's just how it goes I guess. It shouldn't be too difficult to get things working, since the cores are more or less the same. There has been a little accidental build breakage introduced in the 440 code recently (work to support the "Book S" KVM port), but it's all been simple stuff. There's more basic build problems with the kernel at the head of development, but that doesn't seem related to kvm. As for console, you probably want to use qemu's "-nographic" or at least "-serial stdio" options. Thanks for the info. However, "-serial stdio" doesn't seem to work. I get: r...@ebony:~# ./qemu-system-ppcemb --enable-kvm -nographic -m 128 -M bamboo -kernel uImage.bamboo -L . -append "" -m 64 -serial stdio chardev: opening backend "stdio" failed qemu: could not open serial device 'stdio': Success I'm using the qemu at git://git.savannah.nongnu.org/qemu.git, not the one at git://git.kernel.org/pub/scm/virt/kvm/qemu-kvm.git, because the latter wouldn't build. I suppose those are the build problems you speak of. I'll see if I can get the latter working. Thanks a bunch! -corey -- 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: KVM on 440GP
On 22.01.2010, at 18:23, Corey Minyard wrote: > Hollis Blanchard wrote: >> >> >> Thanks! The patch looks good to me. It's unfortunate that 440GP is >> reported is "ppc440gp", while every other 440 variant is reported is >> "ppc440", but that's just how it goes I guess. It shouldn't be too >> difficult to get things working, since the cores are more or less the >> same. There has been a little accidental build breakage introduced in >> the 440 code recently (work to support the "Book S" KVM port), but >> it's all been simple stuff. >> > There's more basic build problems with the kernel at the head of development, > but that doesn't seem related to kvm. > >> As for console, you probably want to use qemu's "-nographic" or at >> least "-serial stdio" options. >> > Thanks for the info. However, "-serial stdio" doesn't seem to work. I get: > > > r...@ebony:~# ./qemu-system-ppcemb --enable-kvm -nographic -m 128 -M bamboo > -kernel uImage.bamboo -L . -append "" -m 64 -serial stdio > chardev: opening backend "stdio" failed > qemu: could not open serial device 'stdio': Success BookE KVM uses virtio console, no? I think that was explained on the wiki too. > I'm using the qemu at git://git.savannah.nongnu.org/qemu.git, not the one at > git://git.kernel.org/pub/scm/virt/kvm/qemu-kvm.git, because the latter > wouldn't build. I suppose those are the build problems you speak of. I'll > see if I can get the latter working. That's the correct one. 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: KVM on 440GP
On Fri, Jan 22, 2010 at 9:27 AM, Alexander Graf wrote: > > On 22.01.2010, at 18:23, Corey Minyard wrote: > >> Hollis Blanchard wrote: >>> As for console, you probably want to use qemu's "-nographic" or at >>> least "-serial stdio" options. >>> >> Thanks for the info. However, "-serial stdio" doesn't seem to work. I get: >> >> r...@ebony:~# ./qemu-system-ppcemb --enable-kvm -nographic -m 128 -M bamboo >> -kernel uImage.bamboo -L . -append "" -m 64 -serial stdio >> chardev: opening backend "stdio" failed >> qemu: could not open serial device 'stdio': Success Haven't seen that one. :( Does the same thing happen if you remove --enable-kvm? If so, it sounds like an issue for qemu-de...@nongnu.org. (No code will actually run like that, since qemu is missing 440 MMU emulation, but it's an easy way to identify the culprit.) > BookE KVM uses virtio console, no? I think that was explained on the wiki too. Sure doesn't. Book E SoCs typically contain NS16550-compatible UARTs, so qemu's normal serial emulation works just fine. -Hollis -- 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: KVM on 440GP
Alexander Graf wrote: I'm using the qemu at git://git.savannah.nongnu.org/qemu.git, not the one at git://git.kernel.org/pub/scm/virt/kvm/qemu-kvm.git, because the latter wouldn't build. I suppose those are the build problems you speak of. I'll see if I can get the latter working. That's the correct one. I assume you mean git://git.kernel.org/pub/scm/virt/kvm/qemu-kvm.git is the correct one. There's lots of problems getting it to compile. There's no support in target-ppc for KVM_CAP_MP_STATE, so I'm currently backing up kernels until I find one that doesn't have that capability. Thanks, -corey -- 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: KVM on 440GP
On 22.01.2010, at 19:29, Corey Minyard wrote: > Alexander Graf wrote: >> >>> I'm using the qemu at git://git.savannah.nongnu.org/qemu.git, not the one >>> at git://git.kernel.org/pub/scm/virt/kvm/qemu-kvm.git, because the latter >>> wouldn't build. I suppose those are the build problems you speak of. I'll >>> see if I can get the latter working. >>> >> >> That's the correct one. >> > I assume you mean git://git.kernel.org/pub/scm/virt/kvm/qemu-kvm.git is the > correct one. > > There's lots of problems getting it to compile. There's no support in > target-ppc for KVM_CAP_MP_STATE, so I'm currently backing up kernels until I > find one that doesn't have that capability. I mean git://git.savannah.nongnu.org/qemu.git is the correct one. The KVM support in qemu-kvm is broken. Same as for S390 :-). 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: KVM on 440GP
Alexander Graf wrote: On 22.01.2010, at 19:29, Corey Minyard wrote: Alexander Graf wrote: I'm using the qemu at git://git.savannah.nongnu.org/qemu.git, not the one at git://git.kernel.org/pub/scm/virt/kvm/qemu-kvm.git, because the latter wouldn't build. I suppose those are the build problems you speak of. I'll see if I can get the latter working. That's the correct one. I assume you mean git://git.kernel.org/pub/scm/virt/kvm/qemu-kvm.git is the correct one. There's lots of problems getting it to compile. There's no support in target-ppc for KVM_CAP_MP_STATE, so I'm currently backing up kernels until I find one that doesn't have that capability. I mean git://git.savannah.nongnu.org/qemu.git is the correct one. The KVM support in qemu-kvm is broken. Same as for S390 :-). Alex Ah, ok, then I am using the right one. I tried using telnet for the console, and it worked for a little while: r...@ebony:~# ./qemu-system-ppcemb --enable-kvm -nographic -m 128 -M bamb oo -kernel uImage.bamboo -L . -append "" -m 64 -serial tcp::,server QEMU waiting for connection on: tcp:0.0.0.0:,server Truncating memory to 64 MiB to fit SDRAM controller limits. QEMU 0.12.50 monitor - type 'help' for more information (qemu) info kvm kvm support: enabled (qemu) So things are getting closer, but there's no output on the telnet screen. Doing an "info registers" causes qemu to abort. Now, nothing should have changed, but it's crashing at startup: r...@ebony:~# ./qemu-system-ppcemb -nographic -m 128 -M bamboo -kernel uI mage.bamboo -L . -append "" -m 64 -serial tcp::,server QEMU waiting for connection on: tcp:0.0.0.0:,server Truncating memory to 64 MiB to fit SDRAM controller limits. QEMU 0.12.0 monitor - type 'help' for more information (qemu) qemu: fatal: Trying to execute code outside RAM or ROM at 0x NIP LR CTR XER MSR HID0 0300 HF idx 0 Segmentatio backtrace show the invalid memory address, and the segfault is due to something happening while printing out the information. Still poking around. -corey -- 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: KVM on 440GP
On Fri, Jan 22, 2010 at 11:13 AM, Corey Minyard wrote: > > I tried using telnet for the console, and it worked for a little while: > > r...@ebony:~# ./qemu-system-ppcemb --enable-kvm -nographic -m 128 -M bamb > oo -kernel uImage.bamboo -L . -append "" -m 64 -serial tcp::,server > QEMU waiting for connection on: tcp:0.0.0.0:,server > Truncating memory to 64 MiB to fit SDRAM controller limits. > QEMU 0.12.50 monitor - type 'help' for more information > (qemu) info kvm > kvm support: enabled > (qemu) > > So things are getting closer, but there's no output on the telnet screen. > > Doing an "info registers" causes qemu to abort. I believe that's a known bug. > Now, nothing should have changed, but it's crashing at startup: > > r...@ebony:~# ./qemu-system-ppcemb -nographic -m 128 -M bamboo -kernel uI > mage.bamboo -L . -append "" -m 64 -serial tcp::,server > QEMU waiting for connection on: tcp:0.0.0.0:,server > Truncating memory to 64 MiB to fit SDRAM controller limits. I don't think it's related, but there must be a silly bug in ppc4xx_sdram_adjust(). 128MB should require just a single bank in the SDRAM controller. > QEMU 0.12.0 monitor - type 'help' for more information > (qemu) qemu: fatal: Trying to execute code outside RAM or ROM at 0x > > NIP LR CTR XER > MSR HID0 0300 HF idx 0 > Segmentatio > > backtrace show the invalid memory address, and the segfault is due to > something happening while printing out the information. If you provide the backtrace, I can see if it looks familiar... -Hollis -- 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: KVM on 440GP
Hollis Blanchard wrote: On Fri, Jan 22, 2010 at 11:13 AM, Corey Minyard wrote: I tried using telnet for the console, and it worked for a little while: r...@ebony:~# ./qemu-system-ppcemb --enable-kvm -nographic -m 128 -M bamb oo -kernel uImage.bamboo -L . -append "" -m 64 -serial tcp::,server QEMU waiting for connection on: tcp:0.0.0.0:,server Truncating memory to 64 MiB to fit SDRAM controller limits. QEMU 0.12.50 monitor - type 'help' for more information (qemu) info kvm kvm support: enabled (qemu) So things are getting closer, but there's no output on the telnet screen. Doing an "info registers" causes qemu to abort. I believe that's a known bug. The following patch, which is almost certainly wrong, works around the problem: diff --git a/hw/ppc440.c b/hw/ppc440.c index abe0a56..03ae356 100644 --- a/hw/ppc440.c +++ b/hw/ppc440.c @@ -44,6 +44,7 @@ CPUState *ppc440ep_init(ram_addr_t *ram_size, PCIBus **pcip, qemu_irq *pic; qemu_irq *irqs; qemu_irq *pci_irqs; +uint32_t sysclk = ; if (cpu_model == NULL) cpu_model = "405"; // XXX: should be 440EP @@ -53,6 +54,9 @@ CPUState *ppc440ep_init(ram_addr_t *ram_size, PCIBus **pcip, exit(1); } +/* Set time-base frequency to sysclk */ +ppc_emb_timers_init(env, sysclk); + ppc_dcr_init(env, NULL, NULL); /* interrupt controller */ Now, nothing should have changed, but it's crashing at startup: r...@ebony:~# ./qemu-system-ppcemb -nographic -m 128 -M bamboo -kernel uI mage.bamboo -L . -append "" -m 64 -serial tcp::,server QEMU waiting for connection on: tcp:0.0.0.0:,server Truncating memory to 64 MiB to fit SDRAM controller limits. I don't think it's related, but there must be a silly bug in ppc4xx_sdram_adjust(). 128MB should require just a single bank in the SDRAM controller. QEMU 0.12.0 monitor - type 'help' for more information (qemu) qemu: fatal: Trying to execute code outside RAM or ROM at 0x NIP LR CTR XER MSR HID0 0300 HF idx 0 Segmentatio backtrace show the invalid memory address, and the segfault is due to something happening while printing out the information. If you provide the backtrace, I can see if it looks familiar... -Hollis Here's how far I can get now: r...@xilinx-ml507:~# ./qemu-system-ppcemb --enable-kvm -nographic -m 64 -M bambo o -kernel uImage.bamboo -L . -append "" -serial tcp::,server QEMU waiting for connection on: tcp:0.0.0.0:,server Truncating memory to 64 MiB to fit SDRAM controller limits. QEMU 0.12.50 monitor - type 'help' for more information (qemu) info cpus * CPU #0: nip=0x (qemu) info registers NIP LR CTR XER MSR HID0 0300 HF idx 0 TB 0bb4 DECR GPR00 00f8 GPR04 GPR08 GPR12 GPR16 GPR20 GPR24 GPR28 CR [ - - - - - - - - ] RES FPR00 FPR04 FPR08 FPR12 FPR16 FPR20 FPR24 FPR28 FPSCR SRR0 SRR1 SDR1 101d23e0 (qemu) x/10x 0 : 0x 0x 0x 0x 0010: 0x 0x 0x 0x 0020: 0x 0x (qemu) So the ROM doesn't seem to be set up properly, though bamboo.dtb is in the current directory. I'm wondering if it is something bad about the memory setup. -corey -- 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
