[PATCH] KVM: MMU: Remove some useless code from alloc_mmu_pages()
If we fail to alloc page for vcpu-arch.mmu.pae_root, call to free_mmu_pages() is unnecessary, which just do free the page malloc for vcpu-arch.mmu.pae_root. Signed-off-by: Wei Yongjun yj...@cn.fujitsu.com --- arch/x86/kvm/mmu.c |7 ++- 1 files changed, 2 insertions(+), 5 deletions(-) diff --git a/arch/x86/kvm/mmu.c b/arch/x86/kvm/mmu.c index 4c3e5b2..5d8e01b 100644 --- a/arch/x86/kvm/mmu.c +++ b/arch/x86/kvm/mmu.c @@ -2849,16 +2849,13 @@ static int alloc_mmu_pages(struct kvm_vcpu *vcpu) */ page = alloc_page(GFP_KERNEL | __GFP_DMA32); if (!page) - goto error_1; + return -ENOMEM; + vcpu-arch.mmu.pae_root = page_address(page); for (i = 0; i 4; ++i) vcpu-arch.mmu.pae_root[i] = INVALID_PAGE; return 0; - -error_1: - free_mmu_pages(vcpu); - return -ENOMEM; } int kvm_mmu_create(struct kvm_vcpu *vcpu) -- 1.6.2.2 -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Setup vcpu add/remove infrastructure, including madt bios_info and dsdt.
On Fri, Jan 22, 2010 at 05:08:32PM +0800, Liu, Jinsong wrote: Gleb Natapov wrote: On Fri, Jan 22, 2010 at 10:15:44AM +0800, Liu, Jinsong wrote: Gleb Natapov wrote: On Thu, Jan 21, 2010 at 07:48:23PM +0800, Liu, Jinsong wrote: From cb997030cba02e7e74a29b3d942aeba9808ed293 Mon Sep 17 00:00:00 2001 From: Liu, Jinsong jinsong@intel.com Date: Fri, 22 Jan 2010 03:18:46 +0800 Subject: [PATCH] Setup vcpu add/remove infrastructure, including madt bios_info and dsdt. 1. setup madt bios_info structure, so that static dsdt get run-time madt info like checksum address, lapic address, max cpu numbers, with least hardcode magic number (realmode address of bios_info). 2. setup vcpu add/remove dsdt infrastructure, including processor related acpi objects and control methods. vcpu add/remove will trigger SCI and then control method _L02. By matching madt, vcpu number and add/remove action were found, then by notify control method, it will notify OS acpi driver. Signed-off-by: Liu, Jinsong jinsong@intel.com It looks like AML code is a port of what we had in BOCHS bios with minor changes. Can you detail what is changed and why for easy review please? And this still doesn't work with Windows I assume. Yes, my work is based on BOCHS infrastructure, thanks BOCHS :) I just change some minor points: 1. explicitly define returen value of '_MAT' as 'buffer', otherwise some linux acpi driver (i.e. linux 2.6.30) would parse error which will handle it as 'integer' not 'buffer'; 2. keep correct 'checksum' of madt when vcpu add/remove, otherwise it will report 'checksum error' when using acpi tools to get madt info if we add/remove vcpu; 3. add '_EJ0' so that linux has acpi obj under /sys/devices/LNXSYSTM:00, which is need for vcpu remove; 4. on Method(PRSC, 0), just scan 'xxx' vcpus that qemu get from cmdline para 'maxcpus=xxx', not all 256 vcpus, otherwise under some dsdt processor define, it will result error; What kind of errors? Qemu should never set bit over maxcpus in PRS. suppose cmdline define vcpus=4, maxvcpus=8 in original BOCHS, will scan 15 lapic items start from lapic0 of madt, where it only has maxvcpus lapic items in madt table, hence there is risk to scan over boundary, scan to other acpi table, and result in wrong vcpu online/offline status (in my test, I meet this situation). Because of this reason, this patch limit scan maxvcpus lapic of madt. But what if cmdline will use vcpu=64? The idea was that \_PR scope will reside in its own ssdt and for each maxvcpus value there will be ssdt with exactly this number of processors. Ideally ssdt will be created dynamically like it is done now, but another solution is to create them at bios compilation time and load correct one at runtime. BTW seabios creates very simple ssdt with \_PR scope right now and I don't see yous patch removes this so you end up with two conflicting \_PR scopes. -- Gleb. -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH] Setup vcpu add/remove infrastructure, including madt bios_info and dsdt.
Gleb Natapov wrote: On Fri, Jan 22, 2010 at 05:08:32PM +0800, Liu, Jinsong wrote: Gleb Natapov wrote: On Fri, Jan 22, 2010 at 10:15:44AM +0800, Liu, Jinsong wrote: Gleb Natapov wrote: On Thu, Jan 21, 2010 at 07:48:23PM +0800, Liu, Jinsong wrote: From cb997030cba02e7e74a29b3d942aeba9808ed293 Mon Sep 17 00:00:00 2001 From: Liu, Jinsong jinsong@intel.com Date: Fri, 22 Jan 2010 03:18:46 +0800 Subject: [PATCH] Setup vcpu add/remove infrastructure, including madt bios_info and dsdt. 1. setup madt bios_info structure, so that static dsdt get run-time madt info like checksum address, lapic address, max cpu numbers, with least hardcode magic number (realmode address of bios_info). 2. setup vcpu add/remove dsdt infrastructure, including processor related acpi objects and control methods. vcpu add/remove will trigger SCI and then control method _L02. By matching madt, vcpu number and add/remove action were found, then by notify control method, it will notify OS acpi driver. Signed-off-by: Liu, Jinsong jinsong@intel.com It looks like AML code is a port of what we had in BOCHS bios with minor changes. Can you detail what is changed and why for easy review please? And this still doesn't work with Windows I assume. Yes, my work is based on BOCHS infrastructure, thanks BOCHS :) I just change some minor points: 1. explicitly define returen value of '_MAT' as 'buffer', otherwise some linux acpi driver (i.e. linux 2.6.30) would parse error which will handle it as 'integer' not 'buffer'; 2. keep correct 'checksum' of madt when vcpu add/remove, otherwise it will report 'checksum error' when using acpi tools to get madt info if we add/remove vcpu; 3. add '_EJ0' so that linux has acpi obj under /sys/devices/LNXSYSTM:00, which is need for vcpu remove; 4. on Method(PRSC, 0), just scan 'xxx' vcpus that qemu get from cmdline para 'maxcpus=xxx', not all 256 vcpus, otherwise under some dsdt processor define, it will result error; What kind of errors? Qemu should never set bit over maxcpus in PRS. suppose cmdline define vcpus=4, maxvcpus=8 in original BOCHS, will scan 15 lapic items start from lapic0 of madt, where it only has maxvcpus lapic items in madt table, hence there is risk to scan over boundary, scan to other acpi table, and result in wrong vcpu online/offline status (in my test, I meet this situation). Because of this reason, this patch limit scan maxvcpus lapic of madt. But what if cmdline will use vcpu=64? The idea was that \_PR scope will reside in its own ssdt and for each maxvcpus value there will be ssdt with exactly this number of processors. Ideally ssdt will be created dynamically like it is done now, but another solution is to create them at bios compilation time and load correct one at runtime. It's OK for vcpu=64. vcpumaxvcpus. if maxvcpus processor defined in dsdt, it's OK since no risk scan (bios only support 15 processor is another story); if processor defined in dsdt maxvcpus, it has risk to scan over boundary. BTW seabios creates very simple ssdt with \_PR scope right now and I don't see yous patch removes this so you end up with two conflicting \_PR scopes. Yes, I just notice \_PR at acpi.c. we can move \_PR to ssdt after ssdt infrastructure was full setup. Thanks, Jinsong-- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[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 yu@freescale.com --- 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 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 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 yu@freescale.com
---
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 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 yu@freescale.com
---
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 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 yu@freescale.com
---
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 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 yu@freescale.com
---
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 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 yu@freescale.com Acked-by: Alexander Graf ag...@suse.de -- To unsubscribe from this list: send the line unsubscribe kvm 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 yu@freescale.com Acked-by: Alexander Graf ag...@suse.de -- To unsubscribe from this list: send the line unsubscribe kvm 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-...@vger.kernel.org; kvm@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 yu@freescale.com
---
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 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 yu@freescale.com
---
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_PPC64
case OP_TRAP_64:
-#else
- vcpu-arch.esr |= ESR_PTR;
#endif
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-...@vger.kernel.org; kvm@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 yu@freescale.com
---
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 in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Setup vcpu add/remove infrastructure, including madt bios_info and dsdt.
On Fri, Jan 22, 2010 at 06:54:42PM +0800, Liu, Jinsong wrote: Gleb Natapov wrote: On Fri, Jan 22, 2010 at 05:08:32PM +0800, Liu, Jinsong wrote: Gleb Natapov wrote: On Fri, Jan 22, 2010 at 10:15:44AM +0800, Liu, Jinsong wrote: Gleb Natapov wrote: On Thu, Jan 21, 2010 at 07:48:23PM +0800, Liu, Jinsong wrote: From cb997030cba02e7e74a29b3d942aeba9808ed293 Mon Sep 17 00:00:00 2001 From: Liu, Jinsong jinsong@intel.com Date: Fri, 22 Jan 2010 03:18:46 +0800 Subject: [PATCH] Setup vcpu add/remove infrastructure, including madt bios_info and dsdt. 1. setup madt bios_info structure, so that static dsdt get run-time madt info like checksum address, lapic address, max cpu numbers, with least hardcode magic number (realmode address of bios_info). 2. setup vcpu add/remove dsdt infrastructure, including processor related acpi objects and control methods. vcpu add/remove will trigger SCI and then control method _L02. By matching madt, vcpu number and add/remove action were found, then by notify control method, it will notify OS acpi driver. Signed-off-by: Liu, Jinsong jinsong@intel.com It looks like AML code is a port of what we had in BOCHS bios with minor changes. Can you detail what is changed and why for easy review please? And this still doesn't work with Windows I assume. Yes, my work is based on BOCHS infrastructure, thanks BOCHS :) I just change some minor points: 1. explicitly define returen value of '_MAT' as 'buffer', otherwise some linux acpi driver (i.e. linux 2.6.30) would parse error which will handle it as 'integer' not 'buffer'; 2. keep correct 'checksum' of madt when vcpu add/remove, otherwise it will report 'checksum error' when using acpi tools to get madt info if we add/remove vcpu; 3. add '_EJ0' so that linux has acpi obj under /sys/devices/LNXSYSTM:00, which is need for vcpu remove; 4. on Method(PRSC, 0), just scan 'xxx' vcpus that qemu get from cmdline para 'maxcpus=xxx', not all 256 vcpus, otherwise under some dsdt processor define, it will result error; What kind of errors? Qemu should never set bit over maxcpus in PRS. suppose cmdline define vcpus=4, maxvcpus=8 in original BOCHS, will scan 15 lapic items start from lapic0 of madt, where it only has maxvcpus lapic items in madt table, hence there is risk to scan over boundary, scan to other acpi table, and result in wrong vcpu online/offline status (in my test, I meet this situation). Because of this reason, this patch limit scan maxvcpus lapic of madt. But what if cmdline will use vcpu=64? The idea was that \_PR scope will reside in its own ssdt and for each maxvcpus value there will be ssdt with exactly this number of processors. Ideally ssdt will be created dynamically like it is done now, but another solution is to create them at bios compilation time and load correct one at runtime. It's OK for vcpu=64. vcpumaxvcpus. if maxvcpus processor defined in dsdt, it's OK since no risk scan (bios only support 15 processor is another story); if processor defined in dsdt maxvcpus, it has risk to scan over boundary. Yes, correct. So why not export maxcpus to DSDT and at the beginning of NTFY check that Arg0 maxcpus then? BTW seabios creates very simple ssdt with \_PR scope right now and I don't see yous patch removes this so you end up with two conflicting \_PR scopes. Yes, I just notice \_PR at acpi.c. we can move \_PR to ssdt after ssdt infrastructure was full setup. Thanks, Jinsong -- Gleb. -- To unsubscribe from this list: send the line unsubscribe kvm 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-...@vger.kernel.org;
kvm@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 yu@freescale.com
---
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 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-...@vger.kernel.org;
kvm@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 yu@freescale.com
---
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_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.
How so? For the handlers that don't take a flags parameter, just add one,
stub it out for Book3S and I'll fix it. The
[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 yu@freescale.com
---
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 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 yu@freescale.com Acked-by: Alexander Graf ag...@suse.de -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
VMs crashing - Ubuntu 8.04, KVM84, libvirt 0.6.1
Hello list, I am using Ubuntu 8.04 with the kvm84 and libvirt 0.6.1 backports. I am experiencing regular crashes of my Vms - well, more like freezes than actual crashes. This is how it looks like: http://waste.mandragor.org/kvmcpu/munin.html * The VM keeps running * The number of LOC IRQs goes down to 0, as well as the number of context switches * The number of processes gradually grows * The weird thing: some processes that were running before the crash keep running, but won't be able to fork (as you can see the munin-node continues to work) This is bothering me a lot and I have absolutely no idea how to fix it or work around it. Has this been experienced by anyone else, and/or fixed in a later version of KVM? -- Yann HAMON Systems Manager Oxford Archaeology: Exploring the Human Journey http://thehumanjourney.net -- Files attached to this email may be in ISO 26300 format (OASIS Open Document Format). If you have difficulty opening them, please visit http://iso26300.info for more information. -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: VMs crashing - Ubuntu 8.04, KVM84, libvirt 0.6.1
On Fri, 2010-01-22 at 11:26 +, Yann Hamon wrote: Hello list, I am using Ubuntu 8.04 with the kvm84 and libvirt 0.6.1 backports. I am experiencing regular crashes of my Vms - well, more like freezes than actual crashes. This is how it looks like: http://waste.mandragor.org/kvmcpu/munin.html * The VM keeps running * The number of LOC IRQs goes down to 0, as well as the number of context switches * The number of processes gradually grows * The weird thing: some processes that were running before the crash keep running, but won't be able to fork (as you can see the munin-node continues to work) This is bothering me a lot and I have absolutely no idea how to fix it or work around it. Has this been experienced by anyone else, and/or fixed in a later version of KVM? I saw your blog post yesterday speaking about it. Unfortunately I don't have much experience with kvm under Ubuntu, so you might want to talk to Dustin, Ubuntu's maintainer of KVM. I saw some replies to your blog post suggesting you to use Dustin's PPA, have you tried to do that? I am copying Dustin on the message. As I said, I am not very knowledgeable with Ubuntu, but perhaps you should try a newer KVM build? kvm-84 is kinda... old :) A backport of a more current codebase to 8.04 could be a good idea. -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Problem with shared L2 cache
Hello! I have following problem with KVM. I have quad-core processor Xeon X7350 ( 8MB L2 cache ). The processor shares 4 MB L2 cache on two cores. By XEN emulation the guest system have 4 MB cache at disposal. xen guest: cat /proc/cpuinfo processor: 3 vendor_id: GenuineIntel cpu family: 6 model: 15 model name: Intel(R) Xeon(R) CPU X7350 @ 2.93GHz stepping: 11 cpu MHz: 2932.026 cache size: 4096 KB fpu: yes fpu_exception: yes cpuid level: 10 wp: yes flags: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat clflush dts mmx fxsr sse sse2 ss syscall nx lm constant_tsc pni ds_cpl cx16 xtpr lahf_lm bogomips: 5865.67 clflush size: 64 cache_alignment: 64 address sizes: 40 bits physical, 48 bits virtual power management: By KVM in the guest system have 2 MB cache at disposal. kvm guest: cat /proc/cpuinfo processor : 3 vendor_id : GenuineIntel cpu family : 6 model : 6 model name : QEMU Virtual CPU version 0.9.1 stepping: 3 cpu MHz : 2932.026 cache size : 2048 KB fpu : yes fpu_exception : yes cpuid level : 2 wp : yes flags : fpu de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 syscall nx lm pni bogomips: 5861.69 clflush size: 64 cache_alignment : 64 address sizes : 40 bits physical, 48 bits virtual power management: On specific loads with the same number of processors, this difference in the cache size leads to negative results. The productivity of the KVM virtual machine shows 2 - 5 times worse results in comparison with XEN virtual machine. Host: cpu: Intel(R) Xeon(R) CPU X7350 @ 2.93GHz os: Centos 5.4 x86_64 kvm:kvm-83-105.el5_4.13 kernel:kernel-2.6.18-164.10.1.el5 kernel arch:x86_64 Guest: os: Centos 5.4 x86_64 qemu command: /usr/libexec/qemu-kvm -S -M pc -m 4096 -smp 4 -name centos -uuid 17136bf5-a7a3-0323-7e9b-90ec5aa06cdb -no-kvm-pit-reinjection -monitor pty -pidfile /var/run/libvirt/qemu//centos.pid -boot c -drive file=/kvm/centos.img,if=virtio,index=0,boot=on,cache=none -net nic,macaddr=52:54:00:43:81:4f,vlan=0,model=virtio -net tap,fd=14,script=,vlan=0,ifname=vnet0 -serial pty -parallel none -usb -vnc 127.0.0.1:0 -k en-us Host CPU: processor: 0 vendor_id: GenuineIntel cpu family: 6 model: 15 model name: Intel(R) Xeon(R) CPU X7350 @ 2.93GHz stepping: 11 cpu MHz: 2931.962 cache size: 4096 KB physical id: 3 siblings: 4 core id: 0 cpu cores: 4 apicid: 12 fpu: yes fpu_exception: yes cpuid level: 10 wp: yes flags: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm syscall nx lm constant_tsc pni monitor ds_cpl vmx est tm2 cx16 xtpr lahf_lm bogomips: 5863.92 clflush size: 64 cache_alignment: 64 address sizes: 40 bits physical, 48 bits virtual power management: processor: 1 vendor_id: GenuineIntel cpu family: 6 model: 15 model name: Intel(R) Xeon(R) CPU X7350 @ 2.93GHz stepping: 11 cpu MHz: 2931.962 cache size: 4096 KB physical id: 8 siblings: 4 core id: 0 cpu cores: 4 apicid: 32 fpu: yes fpu_exception: yes cpuid level: 10 wp: yes flags: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm syscall nx lm constant_tsc pni monitor ds_cpl vmx est tm2 cx16 xtpr lahf_lm bogomips: 5863.11 clflush size: 64 cache_alignment: 64 address sizes: 40 bits physical, 48 bits virtual power management: processor : 2 vendor_id : GenuineIntel cpu family : 6 cpu family : 6 model : 15 model name : Intel(R) Xeon(R) CPU X7350 @ 2.93GHz stepping: 11 cpu MHz : 2931.962 cache size : 4096 KB physical id : 4 siblings: 4 core id : 0 cpu cores : 4 apicid : 16 fpu : yes fpu_exception : yes cpuid level : 10 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm syscall nx lm constant_tsc pni monitor ds_cpl vm x est tm2 cx16 xtpr lahf_lm bogomips: 5863.10 clflush size: 64 clflush size: 64 cache_alignment : 64 address sizes : 40 bits physical, 48 bits virtual power management: processor : 3 vendor_id : GenuineIntel cpu family : 6 model : 15 model name : Intel(R) Xeon(R) CPU X7350 @ 2.93GHz stepping: 11 cpu MHz : 2931.962 cache size : 4096 KB physical id : 15 siblings: 4 core id
Re: Problem with shared L2 cache
You can add the option -cpu host to KVM. Then you get the same cache size information as your host has. Robert On 01/22/10 15:31, Hristo Tomov wrote: Hello! I have following problem with KVM. I have quad-core processor Xeon X7350 ( 8MB L2 cache ). The processor shares 4 MB L2 cache on two cores. By XEN emulation the guest system have 4 MB cache at disposal. xen guest: cat /proc/cpuinfo processor: 3 vendor_id: GenuineIntel cpu family: 6 model: 15 model name: Intel(R) Xeon(R) CPU X7350 @ 2.93GHz stepping: 11 cpu MHz: 2932.026 cache size: 4096 KB fpu: yes fpu_exception: yes cpuid level: 10 wp: yes flags: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat clflush dts mmx fxsr sse sse2 ss syscall nx lm constant_tsc pni ds_cpl cx16 xtpr lahf_lm bogomips: 5865.67 clflush size: 64 cache_alignment: 64 address sizes: 40 bits physical, 48 bits virtual power management: By KVM in the guest system have 2 MB cache at disposal. kvm guest: cat /proc/cpuinfo processor : 3 vendor_id : GenuineIntel cpu family : 6 model : 6 model name : QEMU Virtual CPU version 0.9.1 stepping: 3 cpu MHz : 2932.026 cache size : 2048 KB fpu : yes fpu_exception : yes cpuid level : 2 wp : yes flags : fpu de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 syscall nx lm pni bogomips: 5861.69 clflush size: 64 cache_alignment : 64 address sizes : 40 bits physical, 48 bits virtual power management: On specific loads with the same number of processors, this difference in the cache size leads to negative results. The productivity of the KVM virtual machine shows 2 - 5 times worse results in comparison with XEN virtual machine. Host: cpu: Intel(R) Xeon(R) CPU X7350 @ 2.93GHz os: Centos 5.4 x86_64 kvm:kvm-83-105.el5_4.13 kernel:kernel-2.6.18-164.10.1.el5 kernel arch:x86_64 Guest: os: Centos 5.4 x86_64 qemu command: /usr/libexec/qemu-kvm -S -M pc -m 4096 -smp 4 -name centos -uuid 17136bf5-a7a3-0323-7e9b-90ec5aa06cdb -no-kvm-pit-reinjection -monitor pty -pidfile /var/run/libvirt/qemu//centos.pid -boot c -drive file=/kvm/centos.img,if=virtio,index=0,boot=on,cache=none -net nic,macaddr=52:54:00:43:81:4f,vlan=0,model=virtio -net tap,fd=14,script=,vlan=0,ifname=vnet0 -serial pty -parallel none -usb -vnc 127.0.0.1:0 -k en-us Host CPU: processor: 0 vendor_id: GenuineIntel cpu family: 6 model: 15 model name: Intel(R) Xeon(R) CPU X7350 @ 2.93GHz stepping: 11 cpu MHz: 2931.962 cache size: 4096 KB physical id: 3 siblings: 4 core id: 0 cpu cores: 4 apicid: 12 fpu: yes fpu_exception: yes cpuid level: 10 wp: yes flags: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm syscall nx lm constant_tsc pni monitor ds_cpl vmx est tm2 cx16 xtpr lahf_lm bogomips: 5863.92 clflush size: 64 cache_alignment: 64 address sizes: 40 bits physical, 48 bits virtual power management: processor: 1 vendor_id: GenuineIntel cpu family: 6 model: 15 model name: Intel(R) Xeon(R) CPU X7350 @ 2.93GHz stepping: 11 cpu MHz: 2931.962 cache size: 4096 KB physical id: 8 siblings: 4 core id: 0 cpu cores: 4 apicid: 32 fpu: yes fpu_exception: yes cpuid level: 10 wp: yes flags: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm syscall nx lm constant_tsc pni monitor ds_cpl vmx est tm2 cx16 xtpr lahf_lm bogomips: 5863.11 clflush size: 64 cache_alignment: 64 address sizes: 40 bits physical, 48 bits virtual power management: processor : 2 vendor_id : GenuineIntel cpu family : 6 cpu family : 6 model : 15 model name : Intel(R) Xeon(R) CPU X7350 @ 2.93GHz stepping: 11 cpu MHz : 2931.962 cache size : 4096 KB physical id : 4 siblings: 4 core id : 0 cpu cores : 4 apicid : 16 fpu : yes fpu_exception : yes cpuid level : 10 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm syscall nx lm constant_tsc pni monitor ds_cpl vm x est tm2 cx16 xtpr lahf_lm bogomips: 5863.10 clflush size: 64 clflush size: 64 cache_alignment : 64 address sizes : 40 bits physical, 48
Re: Segfault
Thanks for the hint but unfortunately every qemu command quits with a segfault with this image: scotty images # qemu-nbd nweb.img Segmentation fault [192749.840652] qemu-nbd[16052]: segfault at 7f88b1382000 ip 00419492 sp 7fff1e94f710 error 7 in qemu-nbd[40+31000] It's sad that a segfault of Qemu/KVM can corrupt a whole image while the host itself was running without any problems as the segfault happened. Seems that the data is lost. But thanks again anyway! Robert On 01/22/10 15:35, Liang Guo wrote: 2010/1/20 RW k...@tauceti.net mailto:k...@tauceti.net Is there any chance to get (some) data in the image back? Backup is a few weeks old :-( you may use kvm-nbd or qemu-nbd to present kvm image as a NBD device, so that you can use nbd-client to access them. eg: kvm-nbd /vm/sid1.img modprobe nbd nbd-client localhost 1024 /dev/nbd0 fdisk -l /dev/nbd0 -- Liang Guo http://bluestone.cublog.cn -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH] Setup vcpu add/remove infrastructure, including madt bios_info and dsdt.
Gleb Natapov wrote:
On Fri, Jan 22, 2010 at 06:54:42PM +0800, Liu, Jinsong wrote:
Gleb Natapov wrote:
On Fri, Jan 22, 2010 at 05:08:32PM +0800, Liu, Jinsong wrote:
Gleb Natapov wrote:
On Fri, Jan 22, 2010 at 10:15:44AM +0800, Liu, Jinsong wrote:
Gleb Natapov wrote:
On Thu, Jan 21, 2010 at 07:48:23PM +0800, Liu, Jinsong wrote:
From cb997030cba02e7e74a29b3d942aeba9808ed293 Mon Sep 17
00:00:00 2001
From: Liu, Jinsong jinsong@intel.com
Date: Fri, 22 Jan 2010 03:18:46 +0800
Subject: [PATCH] Setup vcpu add/remove infrastructure,
including madt bios_info and dsdt.
1. setup madt bios_info structure, so that static dsdt
get run-time madt info like checksum address, lapic
address, max cpu numbers, with least hardcode magic
number (realmode address of bios_info).
2. setup vcpu add/remove dsdt infrastructure, including
processor related acpi objects and control methods.
vcpu add/remove will trigger SCI and then control
method _L02. By matching madt, vcpu number and
add/remove action were found, then by notify control
method, it will notify OS acpi driver.
Signed-off-by: Liu, Jinsong jinsong@intel.com
It looks like AML code is a port of what we had in BOCHS bios
with minor changes. Can you detail what is changed and why for
easy review please? And this still doesn't work with Windows I
assume.
Yes, my work is based on BOCHS infrastructure, thanks BOCHS :)
I just change some minor points:
1. explicitly define returen value of '_MAT' as 'buffer',
otherwise some linux acpi driver (i.e. linux 2.6.30) would parse
error which will handle it as 'integer' not 'buffer';
2. keep correct 'checksum' of madt when vcpu add/remove,
otherwise it will report 'checksum error' when using acpi tools
to get madt info if we add/remove vcpu;
3. add '_EJ0' so that linux has acpi obj under
/sys/devices/LNXSYSTM:00, which is need for vcpu remove;
4. on Method(PRSC, 0), just scan 'xxx' vcpus that qemu get from
cmdline para 'maxcpus=xxx', not all 256 vcpus, otherwise under
some dsdt processor define, it will result error;
What kind of errors? Qemu should never set bit over maxcpus in
PRS.
suppose cmdline define vcpus=4, maxvcpus=8
in original BOCHS, will scan 15 lapic items start from lapic0 of
madt, where it only has maxvcpus lapic items in madt table, hence
there is risk to scan over boundary, scan to other acpi table, and
result in wrong vcpu online/offline status (in my test, I meet this
situation). Because of this reason, this patch limit scan maxvcpus
lapic of madt.
But what if cmdline will use vcpu=64? The idea was that \_PR scope
will reside in its own ssdt and for each maxvcpus value there will
be ssdt with exactly this number of processors. Ideally ssdt will be
created dynamically like it is done now, but another solution is to
create them at bios compilation time and load correct one at
runtime.
It's OK for vcpu=64. vcpumaxvcpus.
if maxvcpus processor defined in dsdt, it's OK since no risk scan
(bios only support 15 processor is another story); if processor
defined in dsdt maxvcpus, it has risk to scan over boundary.
Yes, correct. So why not export maxcpus to DSDT and at the beginning
of NTFY check that Arg0 maxcpus then?
Yes, your solution also work.
In fact, we implicitly export maxcpus to DSDT by
struct bios_info {
...
u32 max_cpus_byte; /* max cpus bitmap bytes */
u32 max_cpus_bit; /* max cpus bitmap bits of last byte */
};
this indicate maxvcpus.
In this way it can reduce scan loop.
However, I think it's not key issue. Both are OK.
Just different implement way.
Thanks,
Jinsong
BTW seabios creates very simple ssdt with \_PR scope right now and I
don't see yous patch removes this so you end up with two conflicting
\_PR scopes.
Yes, I just notice \_PR at acpi.c.
we can move \_PR to ssdt after ssdt infrastructure was full setup.
Thanks,
Jinsong
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Unable to single-step in kvm, always results in a resume
Nicholas Amon wrote: So now I can step instruction but my breakpoints do not work. I have verified that disabling kvm restores the breakpoint functionality. Any suggestions? What kind of breakpoints, hardware-assisted or normal BPs? Are you trying to break into real-mode code (as stated below - BTW, top-postings should be avoided!) that happens to run on a non-brand-new Intel host? I never fully tested how well guest debugging works if KVM has to emulate instructions, and I wouldn't be surprised if there are limitations. Jan Jan Kiszka wrote: Hi Nicholas, please don't drop CCs on reply. Nicholas Amon wrote: Hi Jan, Thanks for responding. Yes, I am able to step instruction when I disable kvm w/ the no-kvm option. My host kernel is 64bit 2.6.27 and the program that I am debugging is 32 bit but starts in real mode. But the KVM module I am running is from kvm-88. Is there anyway I can check the version definitively? kvm modules issue a message when being loaded, check your kernel log. qemu-kvm gives you the version via -version. OK, the problems you see is likely related to the very old versions you use. Update to recent kvm-kmod (2.6.32 series) and qemu-kvm (0.12 series) and retry. Jan Thanks, Nicholas Jan Kiszka wrote: Jan Kiszka wrote: Nicholas Amon wrote: Hi All, I am trying to single-step through my kernel using qemu and kvm. I have run qemu via: qemu-system-x86_64 -s -S -hda /home/nickamon/lab1/obj/kernel.img and also connected to the process using gdb. Problem is that whenever I try and step instruction, it seems to resume my kernel rather than allowing me to progress instruction by instruction. I have built the kvm snapshot from git and still no luck. Tried following the code for a few hours and have no luck. Any suggestions? What's you host kernel or kvm-kmod version? ...and does -no-kvm make any difference (except that it's much slower)? Jan -- Siemens AG, Corporate Technology, CT T DE IT 1 Corporate Competence Center Embedded Linux -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: vga stad / vga vmware leads to KVM internal error. Suberror: 1
Hey, On Wed, Jan 20, 2010 at 07:15:02PM +0200, Avi Kivity wrote: On 01/20/2010 07:00 PM, Anthony Liguori wrote: So I have a nice patchset emulating this instruction (quite a pain, since this is the first sse instruction we emulate), but it doesn't help. The guest keeps using it so the display is incredibly slow. Turns out the real problem is somewhere else - the guest is not detecting VBE properly so it is forced to use the old slow vga access. Not sure what the root cause is. Is this with -vga std or -vga vmware? Yes (both reported, I confirmed with -vga std). Is this a VESA driver in the guest? So it seems from the Xorg log. Boot a Ubuntu 9.10 cdrom, on qemu-kvm-0.11 it boots fine and fast, on 0.12 it fails on emulation (unless you apply my patchset, in which case it works, but is incredibly slow). Hm, does it work with any KVM version for you? Tried a couple of revs, but with no success, so I couldn't start bisecting... Best, Dominik -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Setup vcpu add/remove infrastructure, including madt bios_info and dsdt.
On Fri, Jan 22, 2010 at 10:52:29PM +0800, Liu, Jinsong wrote:
Gleb Natapov wrote:
On Fri, Jan 22, 2010 at 06:54:42PM +0800, Liu, Jinsong wrote:
Gleb Natapov wrote:
On Fri, Jan 22, 2010 at 05:08:32PM +0800, Liu, Jinsong wrote:
Gleb Natapov wrote:
On Fri, Jan 22, 2010 at 10:15:44AM +0800, Liu, Jinsong wrote:
Gleb Natapov wrote:
On Thu, Jan 21, 2010 at 07:48:23PM +0800, Liu, Jinsong wrote:
From cb997030cba02e7e74a29b3d942aeba9808ed293 Mon Sep 17
00:00:00 2001
From: Liu, Jinsong jinsong@intel.com
Date: Fri, 22 Jan 2010 03:18:46 +0800
Subject: [PATCH] Setup vcpu add/remove infrastructure,
including madt bios_info and dsdt.
1. setup madt bios_info structure, so that static dsdt
get run-time madt info like checksum address, lapic
address, max cpu numbers, with least hardcode magic
number (realmode address of bios_info).
2. setup vcpu add/remove dsdt infrastructure, including
processor related acpi objects and control methods.
vcpu add/remove will trigger SCI and then control
method _L02. By matching madt, vcpu number and
add/remove action were found, then by notify control
method, it will notify OS acpi driver.
Signed-off-by: Liu, Jinsong jinsong@intel.com
It looks like AML code is a port of what we had in BOCHS bios
with minor changes. Can you detail what is changed and why for
easy review please? And this still doesn't work with Windows I
assume.
Yes, my work is based on BOCHS infrastructure, thanks BOCHS :)
I just change some minor points:
1. explicitly define returen value of '_MAT' as 'buffer',
otherwise some linux acpi driver (i.e. linux 2.6.30) would parse
error which will handle it as 'integer' not 'buffer';
2. keep correct 'checksum' of madt when vcpu add/remove,
otherwise it will report 'checksum error' when using acpi tools
to get madt info if we add/remove vcpu;
3. add '_EJ0' so that linux has acpi obj under
/sys/devices/LNXSYSTM:00, which is need for vcpu remove;
4. on Method(PRSC, 0), just scan 'xxx' vcpus that qemu get from
cmdline para 'maxcpus=xxx', not all 256 vcpus, otherwise under
some dsdt processor define, it will result error;
What kind of errors? Qemu should never set bit over maxcpus in
PRS.
suppose cmdline define vcpus=4, maxvcpus=8
in original BOCHS, will scan 15 lapic items start from lapic0 of
madt, where it only has maxvcpus lapic items in madt table, hence
there is risk to scan over boundary, scan to other acpi table, and
result in wrong vcpu online/offline status (in my test, I meet this
situation). Because of this reason, this patch limit scan maxvcpus
lapic of madt.
But what if cmdline will use vcpu=64? The idea was that \_PR scope
will reside in its own ssdt and for each maxvcpus value there will
be ssdt with exactly this number of processors. Ideally ssdt will be
created dynamically like it is done now, but another solution is to
create them at bios compilation time and load correct one at
runtime.
It's OK for vcpu=64. vcpumaxvcpus.
if maxvcpus processor defined in dsdt, it's OK since no risk scan
(bios only support 15 processor is another story); if processor
defined in dsdt maxvcpus, it has risk to scan over boundary.
Yes, correct. So why not export maxcpus to DSDT and at the beginning
of NTFY check that Arg0 maxcpus then?
Yes, your solution also work.
In fact, we implicitly export maxcpus to DSDT by
struct bios_info {
...
u32 max_cpus_byte; /* max cpus bitmap bytes */
u32 max_cpus_bit; /* max cpus bitmap bits of last byte */
};
this indicate maxvcpus.
In this way it can reduce scan loop.
Actually your scan loop is twice as big as it was in BOCHS because of
this tricks with bytes and bits.
However, I think it's not key issue. Both are OK.
Just different implement way.
The AML code is hard to read as it is, so making it simpler is
important. But the way I want to see this solved in seabios is to create
exactly maxvcpu processors in _PR scope. This will solve MS SVVP problem
too (BOCHS doesn't pass SVVP).
--
Gleb.
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Problem with shared L2 cache
On Fri, Jan 22, 2010 at 04:31:50PM +0200, Hristo Tomov wrote: Hello! I have following problem with KVM. I have quad-core processor Xeon X7350 ( 8MB L2 cache ). The processor shares 4 MB L2 cache on two cores. By XEN emulation the guest system have 4 MB cache at disposal. Cache information is meaningless in virtual environment. Your performance problem lies somewhere else. Trying -cpu host is a good idea nevertheless. -- Gleb. -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: VMs crashing - Ubuntu 8.04, KVM84, libvirt 0.6.1
- Lucas Meneghel Rodrigues l...@redhat.com wrote: On Fri, 2010-01-22 at 11:26 +, Yann Hamon wrote: Hello list, I am using Ubuntu 8.04 with the kvm84 and libvirt 0.6.1 backports. I am experiencing regular crashes of my Vms - well, more like freezes than actual crashes. This is how it looks like: http://waste.mandragor.org/kvmcpu/munin.html * The VM keeps running * The number of LOC IRQs goes down to 0, as well as the number of context switches * The number of processes gradually grows * The weird thing: some processes that were running before the crash keep running, but won't be able to fork (as you can see the munin-node continues to work) This is bothering me a lot and I have absolutely no idea how to fix it or work around it. Has this been experienced by anyone else, and/or fixed in a later version of KVM? I saw your blog post yesterday speaking about it. Unfortunately I don't have much experience with kvm under Ubuntu, so you might want to talk to Dustin, Ubuntu's maintainer of KVM. I saw some replies to your blog post suggesting you to use Dustin's PPA, have you tried to do that? Yes, it's the one I am using - the package has actually been pushed to backports. I did talk to him, but I think they have problems reproducing the bug (it happens fairly rarely, but about once or twice a week for me as I got 50-60 vms). I am copying Dustin on the message. As I said, I am not very knowledgeable with Ubuntu, but perhaps you should try a newer KVM build? I think he is aware of the bug, but quite busy with building the virtualisation infrastructure for 10.4 I'm afraid :) We used to be supported customers (pledged for that backport actually :( ) but aren't anymore, due to some disagreement between my boss and one of their commercials, which is why I thought I would give it a try here. Maybe someone else experienced that bug... kvm-84 is kinda... old :) A backport of a more current codebase to 8.04 could be a good idea. Sure, looking forward to 10.4... Might even uprade to 9.10 if I cant wait til then... -- Files attached to this email may be in ISO 26300 format (OASIS Open Document Format). If you have difficulty opening them, please visit http://iso26300.info for more information. -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH] Setup vcpu add/remove infrastructure, including madt bios_info and dsdt.
Gleb Natapov wrote:
On Fri, Jan 22, 2010 at 10:52:29PM +0800, Liu, Jinsong wrote:
Gleb Natapov wrote:
On Fri, Jan 22, 2010 at 06:54:42PM +0800, Liu, Jinsong wrote:
Gleb Natapov wrote:
On Fri, Jan 22, 2010 at 05:08:32PM +0800, Liu, Jinsong wrote:
Gleb Natapov wrote:
On Fri, Jan 22, 2010 at 10:15:44AM +0800, Liu, Jinsong wrote:
Gleb Natapov wrote:
On Thu, Jan 21, 2010 at 07:48:23PM +0800, Liu, Jinsong wrote:
From cb997030cba02e7e74a29b3d942aeba9808ed293 Mon Sep 17
00:00:00 2001
From: Liu, Jinsong jinsong@intel.com
Date: Fri, 22 Jan 2010 03:18:46 +0800
Subject: [PATCH] Setup vcpu add/remove
infrastructure, including madt bios_info and dsdt.
1. setup madt bios_info structure, so that static
dsdt get run-time madt info like checksum
address, lapic address, max cpu numbers, with
least hardcode magic number (realmode address of
bios_info).
2. setup vcpu add/remove dsdt infrastructure,
including processor related acpi objects and
control methods. vcpu add/remove will trigger SCI
and then control method _L02. By matching madt,
vcpu number and add/remove action were found,
then by notify control
method, it will notify OS acpi driver.
Signed-off-by: Liu, Jinsong jinsong@intel.com
It looks like AML code is a port of what we had in BOCHS bios
with minor changes. Can you detail what is changed and why for
easy review please? And this still doesn't work with Windows
I assume.
Yes, my work is based on BOCHS infrastructure, thanks BOCHS :)
I just change some minor points:
1. explicitly define returen value of '_MAT' as 'buffer',
otherwise some linux acpi driver (i.e. linux 2.6.30) would
parse error which will handle it as 'integer' not 'buffer';
2. keep correct 'checksum' of madt when vcpu add/remove,
otherwise it will report 'checksum error' when using acpi tools
to get madt info if we add/remove vcpu;
3. add '_EJ0' so that linux has acpi obj under
/sys/devices/LNXSYSTM:00, which is need for vcpu remove;
4. on Method(PRSC, 0), just scan 'xxx' vcpus that qemu get from
cmdline para 'maxcpus=xxx', not all 256 vcpus, otherwise under
some dsdt processor define, it will result error;
What kind of errors? Qemu should never set bit over maxcpus in
PRS.
suppose cmdline define vcpus=4, maxvcpus=8
in original BOCHS, will scan 15 lapic items start from lapic0 of
madt, where it only has maxvcpus lapic items in madt table, hence
there is risk to scan over boundary, scan to other acpi table,
and result in wrong vcpu online/offline status (in my test, I
meet this situation). Because of this reason, this patch limit
scan maxvcpus lapic of madt.
But what if cmdline will use vcpu=64? The idea was that \_PR scope
will reside in its own ssdt and for each maxvcpus value there will
be ssdt with exactly this number of processors. Ideally ssdt will
be created dynamically like it is done now, but another solution
is to create them at bios compilation time and load correct one
at runtime.
It's OK for vcpu=64. vcpumaxvcpus.
if maxvcpus processor defined in dsdt, it's OK since no risk scan
(bios only support 15 processor is another story); if processor
defined in dsdt maxvcpus, it has risk to scan over boundary.
Yes, correct. So why not export maxcpus to DSDT and at the beginning
of NTFY check that Arg0 maxcpus then?
Yes, your solution also work.
In fact, we implicitly export maxcpus to DSDT by
struct bios_info {
...
u32 max_cpus_byte; /* max cpus bitmap bytes */
u32 max_cpus_bit; /* max cpus bitmap bits of last byte */ };
this indicate maxvcpus.
In this way it can reduce scan loop.
Actually your scan loop is twice as big as it was in BOCHS because of
this tricks with bytes and bits.
No,
original BOCHS solution: PRSC has 256 loop, and NTFY has 15 scan;
this patch solution: PRSC has maxvcpus loop, and NTFY has min(15,
maxvcpus) scan.
However, I think it's not key issue. Both are OK.
Just different implement way.
The AML code is hard to read as it is, so making it simpler is
important. But the way I want to see this solved in seabios is to
create exactly maxvcpu processors in _PR scope. This will solve MS
SVVP problem too (BOCHS doesn't pass SVVP).
Yes, to create exactly maxvcpu processor is key points.
Thanks,
Jinsong--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Setup vcpu add/remove infrastructure, including madt bios_info and dsdt.
On Fri, Jan 22, 2010 at 11:56:44PM +0800, Liu, Jinsong wrote:
Gleb Natapov wrote:
On Fri, Jan 22, 2010 at 10:52:29PM +0800, Liu, Jinsong wrote:
Gleb Natapov wrote:
On Fri, Jan 22, 2010 at 06:54:42PM +0800, Liu, Jinsong wrote:
Gleb Natapov wrote:
On Fri, Jan 22, 2010 at 05:08:32PM +0800, Liu, Jinsong wrote:
Gleb Natapov wrote:
On Fri, Jan 22, 2010 at 10:15:44AM +0800, Liu, Jinsong wrote:
Gleb Natapov wrote:
On Thu, Jan 21, 2010 at 07:48:23PM +0800, Liu, Jinsong wrote:
From cb997030cba02e7e74a29b3d942aeba9808ed293 Mon Sep 17
00:00:00 2001
From: Liu, Jinsong jinsong@intel.com
Date: Fri, 22 Jan 2010 03:18:46 +0800
Subject: [PATCH] Setup vcpu add/remove
infrastructure, including madt bios_info and dsdt.
1. setup madt bios_info structure, so that static
dsdt get run-time madt info like checksum
address, lapic address, max cpu numbers, with
least hardcode magic number (realmode address of
bios_info).
2. setup vcpu add/remove dsdt infrastructure,
including processor related acpi objects and
control methods. vcpu add/remove will trigger SCI
and then control method _L02. By matching madt,
vcpu number and add/remove action were found,
then by notify control
method, it will notify OS acpi driver.
Signed-off-by: Liu, Jinsong jinsong@intel.com
It looks like AML code is a port of what we had in BOCHS bios
with minor changes. Can you detail what is changed and why for
easy review please? And this still doesn't work with Windows
I assume.
Yes, my work is based on BOCHS infrastructure, thanks BOCHS :)
I just change some minor points:
1. explicitly define returen value of '_MAT' as 'buffer',
otherwise some linux acpi driver (i.e. linux 2.6.30) would
parse error which will handle it as 'integer' not 'buffer';
2. keep correct 'checksum' of madt when vcpu add/remove,
otherwise it will report 'checksum error' when using acpi tools
to get madt info if we add/remove vcpu;
3. add '_EJ0' so that linux has acpi obj under
/sys/devices/LNXSYSTM:00, which is need for vcpu remove;
4. on Method(PRSC, 0), just scan 'xxx' vcpus that qemu get from
cmdline para 'maxcpus=xxx', not all 256 vcpus, otherwise under
some dsdt processor define, it will result error;
What kind of errors? Qemu should never set bit over maxcpus in
PRS.
suppose cmdline define vcpus=4, maxvcpus=8
in original BOCHS, will scan 15 lapic items start from lapic0 of
madt, where it only has maxvcpus lapic items in madt table, hence
there is risk to scan over boundary, scan to other acpi table,
and result in wrong vcpu online/offline status (in my test, I
meet this situation). Because of this reason, this patch limit
scan maxvcpus lapic of madt.
But what if cmdline will use vcpu=64? The idea was that \_PR scope
will reside in its own ssdt and for each maxvcpus value there will
be ssdt with exactly this number of processors. Ideally ssdt will
be created dynamically like it is done now, but another solution
is to create them at bios compilation time and load correct one
at runtime.
It's OK for vcpu=64. vcpumaxvcpus.
if maxvcpus processor defined in dsdt, it's OK since no risk scan
(bios only support 15 processor is another story); if processor
defined in dsdt maxvcpus, it has risk to scan over boundary.
Yes, correct. So why not export maxcpus to DSDT and at the beginning
of NTFY check that Arg0 maxcpus then?
Yes, your solution also work.
In fact, we implicitly export maxcpus to DSDT by
struct bios_info {
...
u32 max_cpus_byte; /* max cpus bitmap bytes */
u32 max_cpus_bit; /* max cpus bitmap bits of last byte */ };
this indicate maxvcpus.
In this way it can reduce scan loop.
Actually your scan loop is twice as big as it was in BOCHS because of
this tricks with bytes and bits.
No,
original BOCHS solution: PRSC has 256 loop, and NTFY has 15 scan;
this patch solution: PRSC has maxvcpus loop, and NTFY has min(15,
maxvcpus) scan.
I what code to be shorter and easier to read, not optimize loop that
will be executed once in a blue moon.
However, I think it's not key issue. Both are OK.
Just different implement way.
The AML code is hard to read as it is, so making it simpler is
important. But the way I want to see this solved in seabios is to
create exactly maxvcpu processors in _PR scope. This will solve MS
SVVP problem too (BOCHS doesn't pass SVVP).
Yes, to create exactly maxvcpu processor is key points.
--
Gleb.
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: repeatable hang with loop mount and heavy IO in guest [SOLVED]
On 01/22/2010 02:57 PM, Michael Tokarev wrote: Antoine Martin wrote: I've tried various guests, including most recent Fedora12 kernels, custom 2.6.32.x All of them hang around the same point (~1GB written) when I do heavy IO write inside the guest. [] Host is running: 2.6.31.4 QEMU PC emulator version 0.10.50 (qemu-kvm-devel-88) Please update to last version and repeat. kvm-88 is ancient and _lots_ of stuff fixed and changed since that time, I doubt anyone here will try to dig into kvm-88 problems. Current kvm is qemu-kvm-0.12.2, released yesterday. Sorry about that, I didn't realize 88 was so far behind. Upgrading to qemu-kvm-0.12.2 did solve my IO problems. Found these build issues if anyone is interested: --enable-io-thread gave me: LINK x86_64-softmmu/qemu-system-x86_64 kvm-all.o: In function `qemu_mutex_lock_iothread': /usr/src/KVM/qemu-kvm-0.12.2/qemu-kvm.c:2526: multiple definition of `qemu_mutex_lock_iothread' vl.o:/usr/src/KVM/qemu-kvm-0.12.2/vl.c:3772: first defined here kvm-all.o: In function `qemu_mutex_unlock_iothread': /usr/src/KVM/qemu-kvm-0.12.2/qemu-kvm.c:2520: multiple definition of `qemu_mutex_unlock_iothread' vl.o:/usr/src/KVM/qemu-kvm-0.12.2/vl.c:3783: first defined here collect2: ld returned 1 exit status And --enable-cap-kvm-pit is defined if you look at --help, but does not exist if you try to use it!? # ./configure --enable-cap-kvm-pit | grep cap-kvm-pit ERROR: unknown option --enable-cap-kvm-pit --disable-cap-kvm-pitdisable KVM pit support --enable-cap-kvm-pit enable KVM pit support Antoine -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: repeatable hang with loop mount and heavy IO in guest [NOT SOLVED]
On 01/23/2010 01:28 AM, Antoine Martin wrote: On 01/22/2010 02:57 PM, Michael Tokarev wrote: Antoine Martin wrote: I've tried various guests, including most recent Fedora12 kernels, custom 2.6.32.x All of them hang around the same point (~1GB written) when I do heavy IO write inside the guest. [] Host is running: 2.6.31.4 QEMU PC emulator version 0.10.50 (qemu-kvm-devel-88) Please update to last version and repeat. kvm-88 is ancient and _lots_ of stuff fixed and changed since that time, I doubt anyone here will try to dig into kvm-88 problems. Current kvm is qemu-kvm-0.12.2, released yesterday. Sorry about that, I didn't realize 88 was so far behind. Upgrading to qemu-kvm-0.12.2 did solve my IO problems. Only for a while. Same problem just re-occurred, only this time it went a little further. It is now just sitting there, with a load average of exactly 3.0 (+- 5%) Here is a good trace of the symptom during writeback, you can see it write the data at around 50MB/s, it goes from being idle to sys, but after a while it just stops writing and goes into mostly wait state: total-cpu-usage -dsk/total- -net/total- ---paging-- ---system-- 1 0 99 0 0 0| 0 0 | 198B 614B| 0 0 | 3617 1 0 99 0 0 0| 0 0 | 198B 710B| 0 0 | 3117 1 1 98 0 0 0| 0 128k| 240B 720B| 0 0 | 3926 1 1 98 0 0 0| 0 0 | 132B 564B| 0 0 | 3114 1 0 99 0 0 0| 0 0 | 132B 468B| 0 0 | 3114 1 1 98 0 0 0| 0 0 | 66B 354B| 0 0 | 3013 0 4 11 85 0 0| 852k0 | 444B 1194B| 0 0 | 215 477 2 2 0 96 0 0| 500k0 | 132B 756B| 0 0 | 169 458 3 57 0 39 1 0| 228k 10M| 132B 692B| 0 0 | 476 5387 6 94 0 0 0 0| 28k 23M| 132B 884B| 0 0 | 373 2142 6 89 0 2 2 0| 40k 38M| 66B 692B| 0 8192B| 502 5651 4 47 0 48 0 0| 140k 34M| 132B 836B| 0 0 | 605 1664 3 64 0 30 2 0| 60k 50M| 132B 370B| 060k| 750 631 4 59 0 35 2 0| 48k 45M| 132B 836B| 028k| 708 1293 7 81 0 10 2 0| 68k 67M| 132B 788B| 0 124k| 928 1634 5 74 0 20 1 0| 48k 48M| 132B 756B| 0 316k| 830 5715 5 70 0 24 1 0| 168k 48M| 132B 676B| 0 100k| 734 5325 4 70 0 24 1 0| 72k 49M| 132B 948B| 088k| 776 3784 5 57 0 37 1 0| 36k 37M| 132B 996B| 0 480k| 602 369 2 21 0 77 0 0| 36k 23M| 132B 724B| 072k| 318 1033 4 51 0 43 2 0| 112k 43M| 132B 756B| 0 112k| 681 909 5 55 0 40 0 0| 88k 48M| 140B 926B| 16k 12k| 698 557 total-cpu-usage -dsk/total- -net/total- ---paging-- ---system-- usr sys idl wai hiq siq| read writ| recv send| in out | int csw 3 45 0 51 1 0|2248k 29M| 198B 1028B| 28k 44k| 681 5468 1 21 0 78 0 0| 92k 17M|1275B 2049B| 92k 52k| 328 1883 3 30 0 66 1 0| 288k 28M| 498B 2116B| 040k| 455 679 1 1 0 98 0 0|4096B0 | 394B 1340B|4096B0 | 4119 1 1 0 98 0 0| 148k 52k| 881B 1592B|4096B 44k| 7561 1 2 0 97 0 0|1408k0 | 351B 1727B| 0 0 | 110 109 2 1 0 97 0 0|8192B0 |1422B 1940B| 0 0 | 5334 1 0 0 99 0 0|4096B 12k| 328B 1018B| 0 0 | 4124 1 4 0 95 0 0| 340k0 |3075B 2152B|4096B0 | 153 191 4 7 0 89 0 0|1004k 44k|1526B 1906B| 0 0 | 254 244 0 1 0 99 0 0| 76k0 | 708B 1708B| 0 0 | 6757 1 1 0 98 0 0| 0 0 | 174B 702B| 0 0 | 3214 1 1 0 98 0 0| 0 0 | 132B 354B| 0 0 | 3211 1 0 0 99 0 0| 0 0 | 132B 468B| 0 0 | 3216 1 0 0 99 0 0| 0 0 | 132B 468B| 0 0 | 3214 1 1 0 98 0 0| 052k| 132B 678B| 0 0 | 4127 1 0 0 99 0 0| 0 0 | 198B 678B| 0 0 | 3517 1 1 0 98 0 0| 0 0 | 198B 468B| 0 0 | 3414 1 0 0 99 0 0| 0 0 | 66B 354B| 0 0 | 2811 1 0 0 99 0 0| 0 0 | 66B 354B| 0 0 | 28 9 1 1 0 98 0 0| 0 0 | 132B 468B| 0 0 | 3416 1 0 0 98 0 1| 0 0 | 66B 354B| 0 0 | 3011 1 1 0 98 0 0| 0 0 | 66B 354B| 0 0 | 2911 From that point onwards, nothing will happen. The host has disk IO to spare... So what is it waiting for?? QEMU PC emulator version 0.12.2 (qemu-kvm-0.12.2), Copyright (c) 2003-2008 Fabrice Bellard Guests: various, all recent kernels. Host: 2.6.31.4 Please advise. Thanks Antoine -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/3] KVM test: Refactoring the 'autotest' subtest
Refactor autotest subtest into a utility function, so other KVM subtests can run autotest control files in hosts as part of their routine. This arrangement was made to accomodate the upcoming 'cpu_hotplug' test. Why not just do the non-autotest part on cpu_hotplug and make autotest.cpu_hotplug dependent on cpu_hotplug? Because: 1) autotest.cpu_hotplug is a valid test on its own, for any situations where smp 1 on qemu virtual machines. 2) Adding cpus to qemu on the fly is pretty broken at the moment (qemu segfaults, no ETA to fix), so skip the autotest.cpu_hotplug test when the cpu_hotplug fails means we won't manage to run the autotest test at all. Why test feature that is not mature then? Because it is there anyway, and by the time it is functional, we'll already have a test for it :) Signed-off-by: Lucas Meneghel Rodrigues l...@redhat.com --- client/tests/kvm/kvm_test_utils.py | 166 +++- client/tests/kvm/tests/autotest.py | 153 ++--- 2 files changed, 172 insertions(+), 147 deletions(-) diff --git a/client/tests/kvm/kvm_test_utils.py b/client/tests/kvm/kvm_test_utils.py index 02ec0cf..a581ca9 100644 --- a/client/tests/kvm/kvm_test_utils.py +++ b/client/tests/kvm/kvm_test_utils.py @@ -23,7 +23,7 @@ More specifically: import time, os, logging, re, commands from autotest_lib.client.common_lib import utils, error -import kvm_utils, kvm_vm, kvm_subprocess +import kvm_utils, kvm_vm, kvm_subprocess, scan_results def get_living_vm(env, vm_name): @@ -203,3 +203,167 @@ def get_time(session, time_command, time_filter_re, time_format): s = re.findall(time_filter_re, s)[0] guest_time = time.mktime(time.strptime(s, time_format)) return (host_time, guest_time) + + +def run_autotest(vm, session, control_path, timeout, test_name, outputdir): + +Run an autotest control file inside a guest (linux only utility). + +@param vm: VM object. +@param session: A shell session on the VM provided. +@param control: An autotest control file. +@param timeout: Timeout under which the autotest test must complete. +@param test_name: Autotest client test name. +@param outputdir: Path on host where we should copy the guest autotest +results to. + +def copy_if_size_differs(vm, local_path, remote_path): + +Copy a file to a guest if it doesn't exist or if its size differs. + +@param vm: VM object. +@param local_path: Local path. +@param remote_path: Remote path. + +copy = False +basename = os.path.basename(local_path) +local_size = os.path.getsize(local_path) +output = session.get_command_output(ls -l %s % remote_path) +if such file in output: +logging.info(Copying %s to guest (remote file is missing) % + basename) +copy = True +else: +try: +remote_size = output.split()[4] +remote_size = int(remote_size) +except IndexError, ValueError: +logging.error(Check for remote path size %s returned %s. + Cannot process., remote_path, output) +raise error.TestFail(Failed to check for %s (Guest died?) % + remote_path) +if remote_size != local_size: +logging.debug(Copying %s to guest due to size mismatch + (remote size %s, local size %s) % + (basename, remote_size, local_size)) +copy = True + +if copy: +if not vm.copy_files_to(local_path, remote_path): +raise error.TestFail(Could not copy %s to guest % local_path) + + +def extract(vm, remote_path, dest_dir=.): + +Extract a .tar.bz2 file on the guest. + +@param vm: VM object +@param remote_path: Remote file path +@param dest_dir: Destination dir for the contents + +basename = os.path.basename(remote_path) +logging.info(Extracting %s... % basename) +(status, output) = session.get_command_status_output( + tar xjvf %s -C %s % (remote_path, dest_dir)) +if status != 0: +logging.error(Uncompress output:\n%s % output) +raise error.TestFail(Could not extract % on guest) + +if not os.path.isfile(control_path): +raise error.TestError(Invalid path to autotest control file: %s % + control_path) + +tarred_autotest_path = /tmp/autotest.tar.bz2 +tarred_test_path = /tmp/%s.tar.bz2 % test_name + +# To avoid problems, let's make the test use the current AUTODIR +# (autotest client path) location +autotest_path = os.environ['AUTODIR'] +tests_path = os.path.join(autotest_path, 'tests') +test_path =
[PATCH 3/3] KVM test: Add cpu_hotplug subtest
Tests the ability of adding virtual cpus on the fly to qemu, then after everything is OK, let's run the cpu_hotplug testsuite on the guest through autotest. When this feature matures, we'll already have functional testing for it, the whole reasoning for doing this was already explained on previous patches. Signed-off-by: Lucas Meneghel Rodrigues l...@redhat.com --- client/tests/kvm/tests/cpu_hotplug.py | 92 client/tests/kvm/tests_base.cfg.sample |5 ++ 2 files changed, 97 insertions(+), 0 deletions(-) create mode 100644 client/tests/kvm/tests/cpu_hotplug.py diff --git a/client/tests/kvm/tests/cpu_hotplug.py b/client/tests/kvm/tests/cpu_hotplug.py new file mode 100644 index 000..013b45a --- /dev/null +++ b/client/tests/kvm/tests/cpu_hotplug.py @@ -0,0 +1,92 @@ +import os, logging, re +from autotest_lib.client.common_lib import error +from autotest_lib.client.bin import utils +import kvm_subprocess, kvm_utils, kvm_test_utils + +def run_cpu_hotplug(test, params, env): + +Runs CPU hotplug test: + +1) Pick up a living guest +2) Send the monitor command cpu_set [n cpus] +3) Verify if guest has the additional CPU showing up under +/sys/devices/system/cpu +4) Try to bring it online by writing 1 to the 'online' file inside that dir +5) Run the CPU Hotplug test suite shipped with autotest inside guest + +@param test: kvm test object. +@param params: Dictionary with test parameters. +@param env: Dictionary with the test environment. + +vm = kvm_test_utils.get_living_vm(env, params.get(main_vm)) +session = kvm_test_utils.wait_for_login(vm) + +n_cpus_add = int(params.get(n_cpus_add, 1)) +current_cpus = int(params.get(smp, 1)) +total_cpus = current_cpus + n_cpus_add +# As of today (01-21-2010) it is unlikely that we're going to raise the +# number of processors of a VM to anywhere near 100, but still, it's good +# to put some boundaries to the test +if total_cpus 100: +raise error.TestError(Unsupported number of total CPUs: %s. + Please choose a smaller number. % total_cpus) + +dmesg_before = session.get_command_output(dmesg -c) + +logging.info(Adding %d CPUs to guest % n_cpus_add) +(ret, output) = vm.send_monitor_cmd(cpu_set %s online % total_cpus) +if ret != 0: +raise error.TestFail(Failed to add CPUs to guest: %s % output) + +dmesg_after = session.get_command_output(dmesg -c) + +logging.debug(Guest dmesg output after CPU add:\n%s % dmesg_after) + +# Verify whether the new cpus are showing up on /sys +n_cmd = 'find /sys/devices/system/cpu/cpu[0-99] -maxdepth 0 -type d | wc -l' +try: +cpus_after_addition = int(session.get_command_output(n_cmd)) +except ValueError: +raise error.TestFail(Unable to get CPU count after CPU addition + (Guest dead?)) + +if cpus_after_addition != total_cpus: +raise error.TestFail(%s CPUs are showing up under + /sys/devices/system/cpu, was expecting %s % + (cpus_after_addition, total_cpus)) + +r_cmd = 'find /sys/devices/system/cpu/cpu[0-99]/online -maxdepth 0 -type f' +online_files = session.get_command_output(r_cmd).split().sort() + +if not online_files: +raise error.TestFail(Could not find CPUs that can be + enabled/disabled on guest) + +for online_file in online_files: +cpu_regexp = re.compile(cpu(\d+), re.IGNORECASE) +cpu_id = cpu_regexp.findall(online_file)[0] +try: +online_status = int(session.get_command_output(cat %s % + online_file)) +except ValueError: +raise error.TestFail(Unable to get online status from CPU %s + (Guest dead?) % cpu_id) +if online_status == 0: +logging.debug(CPU %s offline, bringing it online % cpu_id) +rc = session.get_command_status(echo 1 %s % online_file) +if rc != 0: +raise error.TestError(Error bringing guest CPU %s online % + cpu_id) + +# Now that all CPUs were onlined, let's execute the +# autotest CPU Hotplug test +timeout = int(params.get(cpu_hotplug_timeout)) +test_name = cpu_hotplug +control_path = os.path.join(test.bindir, autotest_control, +cpu_hotplug.control) +outputdir = test.outputdir + +logging.info(Executing CPU hotplug autotest on guest) +kvm_test_utils.run_autotest(vm, session, control_path, timeout, test_name, +outputdir) + diff --git a/client/tests/kvm/tests_base.cfg.sample b/client/tests/kvm/tests_base.cfg.sample index e48f1d2..a1af395 100644 --- a/client/tests/kvm/tests_base.cfg.sample +++
Re: regression between 0.12.1.2 and 0.12.2
Toralf Förster wrote: Hi, under a mostly stable Gentoo I observed this new msg : tfoer...@n22 ~/virtual/kvm $ qemu -hda gentoo_kdevm.img -hdb portage_kdeprefix.img -hdd swap.img -smp 2 -m 768 -vga std -soundhw es1370 BUG: kvm_dirty_pages_log_enable_slot: invalid parameters BUG: kvm_dirty_pages_log_disable_slot: invalid parameters .. The kvm image can be derived from http://dev.gentooexperimental.org/~wired/kvm/ . My system is a : tfoer...@n22 ~/virtual/kvm $ uname -a Linux n22 2.6.32.4 #1 SMP Mon Jan 18 20:20:38 CET 2010 i686 Intel(R) Core(TM)2 Duo CPU P8600 @ 2.40GHz GenuineIntel GNU/Linux That's a pre-0.12.1.2 qemu-kvm issue, upstream is not affected - or is at least not reporting it. It's already in my todo queue, just waiting to be dequeued. Jan signature.asc Description: OpenPGP digital signature
Re: virtio bonding bandwidth problem
On Friday 22 January 2010 07:52:49 am Didier Moens wrote:
(initially posted to libvirt-us...@redhat.com, but by request of Daniel
P. Berrange cross-posted to this list)
Dear all,
I have been wrestling with this issue for the past few days ; googling
around doesn't seem to yield anything useful, hence this cry for help.
Setup (RHEL5.4) :
* kernel-2.6.18-164.10.1.el5
* kvm-83-105.el5
* libvirt-0.6.3-20.el5
* net.bridge.bridge-nf-call-{arp,ip,ip6}tables = 0
* tested with/without jumbo frames
- I am running several RHEL5.4 KVM virtio guest instances on a Dell PE
R805 RHEL5.4 host. Host and guests are fully updated ; I am using iperf
to test available bandwidth from 3 different locations (clients) in the
network to both the host and the guests .
- To increase both bandwidth and fail-over, 3 1Gb network interfaces
(BCM5708, bnx2 driver) on the host are bonded (802.3ad) to a 3 Gb/s
bond0, which is bridged. As all guest interfaces are connected to the
bridge, I would expect total available bandwidth to all guests to be in
the range of 2-2.5 Gb/s.
- Testing with one external client connection to the bare metal host
yields approx. 940 Mb/s ;
- Testing with 3 simultaneous connections to the host yields 2.5 Gb/s,
which confirms a successful bonding setup.
Problem :
Unfortunately, available bandwidth to the guests proves to be problematic :
1. One client to one guest : 250-600 Mb/s ;
2a. One client to 3 guests : 300-350 Mb/s to each guest, total not
exceeding 980 Mb/s;
2b. Three clients to 3 guests : 300-350 Mb/s to each guest ;
2c. Three clients to host and 2 guests : 940 Mb/s (host) + 500 Mb/s to
each guest.
Conclusions :
1. I am experiencing a 40% performance hit (600 Mb/s) on each individual
virtio guest connection ;
I don't know what all features RHEL5.4 enables for kvm, but that doesn't seem
outside the realm of possibility. Especially depending on what OS is running
in the guest. I think RHEL5.4 has an older version of virtio, but I won't
swear to it. Fwiw, I get ~1.5Gbps guest to host on a Ubuntu 9.10 guest,
~850mbit/s guest to host on a Windows 7 guest. To get those speeds, I have to
up the window sizes a good bit (the default is 8K, those numbers are at 1M).
At the default Windows 7 gets ~250mbit/s.
2. Total simultaneous bandwidth to all guests seems to be capped at 1
Gb/s ; quite problematic, as this renders my server consolidation almost
useless.
I don't know about 802.3ad bonding, but I know the other linux bonding
techniques are very hard to benchmark due to the way the mac's are handled. I
would start by examining/describing your testing a little more. At the very
least what tools you're using to test, etc. would be helpful.
I could bridge each host network interface separately and assign guest
interfaces by hand, but that would defy the whole idea of load balancing
and failover which is provided by the host bonding.
Any ideas anyone, or am I peeking in the wrong direction (clueless
setup, flawed testing methodology, ...) ?
I monitor the list; a CC: would be appreciated.
Thanks in advance for any help,
Didier
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[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 yu@freescale.com --- 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 yu@freescale.com
---
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 yu@freescale.com
---
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 yu@freescale.com
---
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 yu@freescale.com
---
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 yu@freescale.com Acked-by: Alexander Graf ag...@suse.de -- 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 yu@freescale.com Acked-by: Alexander Graf ag...@suse.de -- 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 yu@freescale.com
---
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 yu@freescale.com
---
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_PPC64
case OP_TRAP_64:
-#else
- vcpu-arch.esr |= ESR_PTR;
#endif
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 yu@freescale.com
---
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 yu@freescale.com
---
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_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.
How so? For the handlers that don't take a flags parameter, just add one,
stub it out for Book3S and I'll fix it. The
[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 yu@freescale.com
---
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
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 miny...@acm.org 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 ag...@suse.de 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
