* [PATCH 30/37] KVM: PPC: bookehv: add comment about shadow_msr
From: Alexander Graf @ 2012-02-24 14:26 UTC (permalink / raw)
To: kvm-ppc; +Cc: Scott Wood, linuxppc-dev, kvm
In-Reply-To: <1330093591-19523-1-git-send-email-agraf@suse.de>
For BookE HV the guest visible MSR is shared->msr and is identical to
the MSR that is in use while the guest is running, because we can't trap
reads from/to MSR.
So shadow_msr is unused there. Indicate that with a comment.
Signed-off-by: Alexander Graf <agraf@suse.de>
---
arch/powerpc/include/asm/kvm_host.h | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/include/asm/kvm_host.h b/arch/powerpc/include/asm/kvm_host.h
index ed95f53..633d68f 100644
--- a/arch/powerpc/include/asm/kvm_host.h
+++ b/arch/powerpc/include/asm/kvm_host.h
@@ -386,6 +386,7 @@ struct kvm_vcpu_arch {
#endif
u32 vrsave; /* also USPRG0 */
u32 mmucr;
+ /* shadow_msr is unused for BookE HV */
ulong shadow_msr;
ulong csrr0;
ulong csrr1;
--
1.6.0.2
^ permalink raw reply related
* [PATCH 31/37] KVM: PPC: booke: Readd debug abort code for machine check
From: Alexander Graf @ 2012-02-24 14:26 UTC (permalink / raw)
To: kvm-ppc; +Cc: Scott Wood, linuxppc-dev, kvm
In-Reply-To: <1330093591-19523-1-git-send-email-agraf@suse.de>
When during guest execution we get a machine check interrupt, we don't
know how to handle it yet. So let's add the error printing code back
again that we dropped accidently earlier and tell user space that something
went really wrong.
Signed-off-by: Alexander Graf <agraf@suse.de>
---
arch/powerpc/kvm/booke.c | 7 ++++++-
1 files changed, 6 insertions(+), 1 deletions(-)
diff --git a/arch/powerpc/kvm/booke.c b/arch/powerpc/kvm/booke.c
index 288bc05..451ba16 100644
--- a/arch/powerpc/kvm/booke.c
+++ b/arch/powerpc/kvm/booke.c
@@ -632,7 +632,12 @@ int kvmppc_handle_exit(struct kvm_run *run, struct kvm_vcpu *vcpu,
switch (exit_nr) {
case BOOKE_INTERRUPT_MACHINE_CHECK:
- r = RESUME_GUEST;
+ printk("MACHINE CHECK: %lx\n", mfspr(SPRN_MCSR));
+ kvmppc_dump_vcpu(vcpu);
+ /* For debugging, send invalid exit reason to user space */
+ run->hw.hardware_exit_reason = ~1ULL << 32;
+ run->hw.hardware_exit_reason |= mfspr(SPRN_MCSR);
+ r = RESUME_HOST;
break;
case BOOKE_INTERRUPT_EXTERNAL:
--
1.6.0.2
^ permalink raw reply related
* [PATCH 32/37] KVM: PPC: booke: add GS documentation for program interrupt
From: Alexander Graf @ 2012-02-24 14:26 UTC (permalink / raw)
To: kvm-ppc; +Cc: Scott Wood, linuxppc-dev, kvm
In-Reply-To: <1330093591-19523-1-git-send-email-agraf@suse.de>
The comment for program interrupts triggered when using bookehv was
misleading. Update it to mention why MSR_GS indicates that we have
to inject an interrupt into the guest again, not emulate it.
Signed-off-by: Alexander Graf <agraf@suse.de>
---
arch/powerpc/kvm/booke.c | 10 ++++++++--
1 files changed, 8 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/kvm/booke.c b/arch/powerpc/kvm/booke.c
index 451ba16..7adef28 100644
--- a/arch/powerpc/kvm/booke.c
+++ b/arch/powerpc/kvm/booke.c
@@ -683,8 +683,14 @@ int kvmppc_handle_exit(struct kvm_run *run, struct kvm_vcpu *vcpu,
case BOOKE_INTERRUPT_PROGRAM:
if (vcpu->arch.shared->msr & (MSR_PR | MSR_GS)) {
- /* Program traps generated by user-level software must be handled
- * by the guest kernel. */
+ /*
+ * Program traps generated by user-level software must
+ * be handled by the guest kernel.
+ *
+ * In GS mode, hypervisor privileged instructions trap
+ * on BOOKE_INTERRUPT_HV_PRIV, not here, so these are
+ * actual program interrupts, handled by the guest.
+ */
kvmppc_core_queue_program(vcpu, vcpu->arch.fault_esr);
r = RESUME_GUEST;
kvmppc_account_exit(vcpu, USR_PR_INST);
--
1.6.0.2
^ permalink raw reply related
* [PATCH 29/37] KVM: PPC: bookehv: disable MAS register updates early
From: Alexander Graf @ 2012-02-24 14:26 UTC (permalink / raw)
To: kvm-ppc; +Cc: Scott Wood, linuxppc-dev, kvm
In-Reply-To: <1330093591-19523-1-git-send-email-agraf@suse.de>
We need to make sure that no MAS updates happen automatically while we
have the guest MAS registers loaded. So move the disabling code a bit
higher up so that it covers the full time we have guest values in MAS
registers.
The race this patch fixes should never occur, but it makes the code a
bit more logical to do it this way around.
Signed-off-by: Alexander Graf <agraf@suse.de>
---
arch/powerpc/kvm/bookehv_interrupts.S | 10 ++++++----
1 files changed, 6 insertions(+), 4 deletions(-)
diff --git a/arch/powerpc/kvm/bookehv_interrupts.S b/arch/powerpc/kvm/bookehv_interrupts.S
index 469bd3f..021d087 100644
--- a/arch/powerpc/kvm/bookehv_interrupts.S
+++ b/arch/powerpc/kvm/bookehv_interrupts.S
@@ -358,6 +358,7 @@ _GLOBAL(kvmppc_resume_host)
mtspr SPRN_MAS4, r6
stw r5, VCPU_SHARED_MAS7_3+0(r11)
mtspr SPRN_MAS6, r8
+ /* Enable MAS register updates via exception */
mfspr r3, SPRN_EPCR
rlwinm r3, r3, 0, ~SPRN_EPCR_DMIUH
mtspr SPRN_EPCR, r3
@@ -515,6 +516,11 @@ lightweight_exit:
mtspr SPRN_PID, r3
PPC_LL r11, VCPU_SHARED(r4)
+ /* Disable MAS register updates via exception */
+ mfspr r3, SPRN_EPCR
+ oris r3, r3, SPRN_EPCR_DMIUH@h
+ mtspr SPRN_EPCR, r3
+ isync
/* Save host mas4 and mas6 and load guest MAS registers */
mfspr r3, SPRN_MAS4
stw r3, VCPU_HOST_MAS4(r4)
@@ -538,10 +544,6 @@ lightweight_exit:
lwz r5, VCPU_SHARED_MAS7_3+0(r11)
mtspr SPRN_MAS6, r3
mtspr SPRN_MAS7, r5
- /* Disable MAS register updates via exception */
- mfspr r3, SPRN_EPCR
- oris r3, r3, SPRN_EPCR_DMIUH@h
- mtspr SPRN_EPCR, r3
/*
* Host interrupt handlers may have clobbered these guest-readable
--
1.6.0.2
^ permalink raw reply related
* [PATCH 27/37] KVM: PPC: bookehv: remove negation for CONFIG_64BIT
From: Alexander Graf @ 2012-02-24 14:26 UTC (permalink / raw)
To: kvm-ppc; +Cc: Scott Wood, linuxppc-dev, kvm
In-Reply-To: <1330093591-19523-1-git-send-email-agraf@suse.de>
Instead if doing
#ifndef CONFIG_64BIT
...
#else
...
#endif
we should rather do
#ifdef CONFIG_64BIT
...
#else
...
#endif
which is a lot easier to read. Change the bookehv implementation to
stick with this rule.
Signed-off-by: Alexander Graf <agraf@suse.de>
---
arch/powerpc/kvm/bookehv_interrupts.S | 24 ++++++++++++------------
1 files changed, 12 insertions(+), 12 deletions(-)
diff --git a/arch/powerpc/kvm/bookehv_interrupts.S b/arch/powerpc/kvm/bookehv_interrupts.S
index 215381e..c5a0796 100644
--- a/arch/powerpc/kvm/bookehv_interrupts.S
+++ b/arch/powerpc/kvm/bookehv_interrupts.S
@@ -99,10 +99,10 @@
.endif
oris r8, r6, MSR_CE@h
-#ifndef CONFIG_64BIT
- stw r6, (VCPU_SHARED_MSR + 4)(r11)
-#else
+#ifdef CONFIG_64BIT
std r6, (VCPU_SHARED_MSR)(r11)
+#else
+ stw r6, (VCPU_SHARED_MSR + 4)(r11)
#endif
ori r8, r8, MSR_ME | MSR_RI
PPC_STL r5, VCPU_PC(r4)
@@ -344,10 +344,10 @@ _GLOBAL(kvmppc_resume_host)
stw r5, VCPU_SHARED_MAS0(r11)
mfspr r7, SPRN_MAS2
stw r6, VCPU_SHARED_MAS1(r11)
-#ifndef CONFIG_64BIT
- stw r7, (VCPU_SHARED_MAS2 + 4)(r11)
-#else
+#ifdef CONFIG_64BIT
std r7, (VCPU_SHARED_MAS2)(r11)
+#else
+ stw r7, (VCPU_SHARED_MAS2 + 4)(r11)
#endif
mfspr r5, SPRN_MAS3
mfspr r6, SPRN_MAS4
@@ -530,10 +530,10 @@ lightweight_exit:
stw r3, VCPU_HOST_MAS6(r4)
lwz r3, VCPU_SHARED_MAS0(r11)
lwz r5, VCPU_SHARED_MAS1(r11)
-#ifndef CONFIG_64BIT
- lwz r6, (VCPU_SHARED_MAS2 + 4)(r11)
-#else
+#ifdef CONFIG_64BIT
ld r6, (VCPU_SHARED_MAS2)(r11)
+#else
+ lwz r6, (VCPU_SHARED_MAS2 + 4)(r11)
#endif
lwz r7, VCPU_SHARED_MAS7_3+4(r11)
lwz r8, VCPU_SHARED_MAS4(r11)
@@ -572,10 +572,10 @@ lightweight_exit:
PPC_LL r6, VCPU_CTR(r4)
PPC_LL r7, VCPU_CR(r4)
PPC_LL r8, VCPU_PC(r4)
-#ifndef CONFIG_64BIT
- lwz r9, (VCPU_SHARED_MSR + 4)(r11)
-#else
+#ifdef CONFIG_64BIT
ld r9, (VCPU_SHARED_MSR)(r11)
+#else
+ lwz r9, (VCPU_SHARED_MSR + 4)(r11)
#endif
PPC_LL r0, VCPU_GPR(r0)(r4)
PPC_LL r1, VCPU_GPR(r1)(r4)
--
1.6.0.2
^ permalink raw reply related
* [PATCH 34/37] KVM: PPC: e500: fix typo in tlb code
From: Alexander Graf @ 2012-02-24 14:26 UTC (permalink / raw)
To: kvm-ppc; +Cc: Scott Wood, linuxppc-dev, kvm
In-Reply-To: <1330093591-19523-1-git-send-email-agraf@suse.de>
The tlbncfg registers should be populated with their respective TLB's
values. Fix the obvious typo.
Signed-off-by: Alexander Graf <agraf@suse.de>
---
arch/powerpc/kvm/e500_tlb.c | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/kvm/e500_tlb.c b/arch/powerpc/kvm/e500_tlb.c
index 279e10a..e05232b 100644
--- a/arch/powerpc/kvm/e500_tlb.c
+++ b/arch/powerpc/kvm/e500_tlb.c
@@ -1268,8 +1268,8 @@ int kvmppc_e500_tlb_init(struct kvmppc_vcpu_e500 *vcpu_e500)
vcpu->arch.tlbcfg[1] = mfspr(SPRN_TLB1CFG) &
~(TLBnCFG_N_ENTRY | TLBnCFG_ASSOC);
- vcpu->arch.tlbcfg[0] |= vcpu_e500->gtlb_params[1].entries;
- vcpu->arch.tlbcfg[0] |=
+ vcpu->arch.tlbcfg[1] |= vcpu_e500->gtlb_params[1].entries;
+ vcpu->arch.tlbcfg[1] |=
vcpu_e500->gtlb_params[1].ways << TLBnCFG_ASSOC_SHIFT;
return 0;
--
1.6.0.2
^ permalink raw reply related
* [PATCH 33/37] KVM: PPC: bookehv: remove unused code
From: Alexander Graf @ 2012-02-24 14:26 UTC (permalink / raw)
To: kvm-ppc; +Cc: Scott Wood, linuxppc-dev, kvm
In-Reply-To: <1330093591-19523-1-git-send-email-agraf@suse.de>
There was some unused code in the exit code path that must have been
a leftover from earlier iterations. While it did no hard, it's superfluous
and thus should be removed.
Signed-off-by: Alexander Graf <agraf@suse.de>
---
arch/powerpc/kvm/bookehv_interrupts.S | 3 ---
1 files changed, 0 insertions(+), 3 deletions(-)
diff --git a/arch/powerpc/kvm/bookehv_interrupts.S b/arch/powerpc/kvm/bookehv_interrupts.S
index 021d087..b1c099b 100644
--- a/arch/powerpc/kvm/bookehv_interrupts.S
+++ b/arch/powerpc/kvm/bookehv_interrupts.S
@@ -112,9 +112,6 @@
* appropriate for the exception type).
*/
cmpw r6, r8
- .if \flags & NEED_EMU
- lwz r9, KVM_LPID(r9)
- .endif
beq 1f
mfmsr r7
.if \srr0 != SPRN_MCSRR0 && \srr0 != SPRN_CSRR0
--
1.6.0.2
^ permalink raw reply related
* [PATCH 35/37] KVM: PPC: booke: Support perfmon interrupts
From: Alexander Graf @ 2012-02-24 14:26 UTC (permalink / raw)
To: kvm-ppc; +Cc: Scott Wood, linuxppc-dev, kvm
In-Reply-To: <1330093591-19523-1-git-send-email-agraf@suse.de>
When during guest context we get a performance monitor interrupt, we
currently bail out and oops. Let's route it to its correct handler
instead.
Signed-off-by: Alexander Graf <agraf@suse.de>
---
arch/powerpc/kvm/booke.c | 4 ++++
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/kvm/booke.c b/arch/powerpc/kvm/booke.c
index 7adef28..423701b 100644
--- a/arch/powerpc/kvm/booke.c
+++ b/arch/powerpc/kvm/booke.c
@@ -677,6 +677,10 @@ int kvmppc_handle_exit(struct kvm_run *run, struct kvm_vcpu *vcpu,
r = RESUME_GUEST;
break;
+ case BOOKE_INTERRUPT_PERFORMANCE_MONITOR:
+ r = RESUME_GUEST;
+ break;
+
case BOOKE_INTERRUPT_HV_PRIV:
r = emulation_exit(run, vcpu);
break;
--
1.6.0.2
^ permalink raw reply related
* [PATCH 36/37] KVM: PPC: booke: expose guest registers on irq reinject
From: Alexander Graf @ 2012-02-24 14:26 UTC (permalink / raw)
To: kvm-ppc; +Cc: Scott Wood, linuxppc-dev, kvm
In-Reply-To: <1330093591-19523-1-git-send-email-agraf@suse.de>
When reinjecting an interrupt into the host interrupt handler after we're
back in host kernel land, let's tell the kernel about all the guest state
that the interrupt happened at.
This helps getting reasonable numbers out of perf.
Signed-off-by: Alexander Graf <agraf@suse.de>
---
arch/powerpc/kvm/booke.c | 54 +++++++++++++++++++++++++++++++++------------
1 files changed, 39 insertions(+), 15 deletions(-)
diff --git a/arch/powerpc/kvm/booke.c b/arch/powerpc/kvm/booke.c
index 423701b..709fd45 100644
--- a/arch/powerpc/kvm/booke.c
+++ b/arch/powerpc/kvm/booke.c
@@ -593,37 +593,61 @@ static int emulation_exit(struct kvm_run *run, struct kvm_vcpu *vcpu)
}
}
-/**
- * kvmppc_handle_exit
- *
- * Return value is in the form (errcode<<2 | RESUME_FLAG_HOST | RESUME_FLAG_NV)
- */
-int kvmppc_handle_exit(struct kvm_run *run, struct kvm_vcpu *vcpu,
- unsigned int exit_nr)
+static void kvmppc_fill_pt_regs(struct kvm_vcpu *vcpu, struct pt_regs *regs)
{
- int r = RESUME_HOST;
+ int i;
- /* update before a new last_exit_type is rewritten */
- kvmppc_update_timing_stats(vcpu);
+ for (i = 0; i < 32; i++)
+ regs->gpr[i] = kvmppc_get_gpr(vcpu, i);
+ regs->nip = vcpu->arch.pc;
+ regs->msr = vcpu->arch.shared->msr;
+ regs->ctr = vcpu->arch.ctr;
+ regs->link = vcpu->arch.lr;
+ regs->xer = kvmppc_get_xer(vcpu);
+ regs->ccr = kvmppc_get_cr(vcpu);
+ regs->dar = get_guest_dear(vcpu);
+ regs->dsisr = get_guest_esr(vcpu);
+}
+
+static void kvmppc_restart_interrupt(struct kvm_vcpu *vcpu,
+ unsigned int exit_nr)
+{
+ struct pt_regs regs = *current->thread.regs;
+ kvmppc_fill_pt_regs(vcpu, ®s);
switch (exit_nr) {
case BOOKE_INTERRUPT_EXTERNAL:
- do_IRQ(current->thread.regs);
+ do_IRQ(®s);
break;
-
case BOOKE_INTERRUPT_DECREMENTER:
- timer_interrupt(current->thread.regs);
+ timer_interrupt(®s);
break;
-
#if defined(CONFIG_PPC_FSL_BOOK3E) || defined(CONFIG_PPC_BOOK3E_64)
case BOOKE_INTERRUPT_DOORBELL:
- doorbell_exception(current->thread.regs);
+ doorbell_exception(®s);
break;
#endif
case BOOKE_INTERRUPT_MACHINE_CHECK:
/* FIXME */
break;
}
+}
+
+/**
+ * kvmppc_handle_exit
+ *
+ * Return value is in the form (errcode<<2 | RESUME_FLAG_HOST | RESUME_FLAG_NV)
+ */
+int kvmppc_handle_exit(struct kvm_run *run, struct kvm_vcpu *vcpu,
+ unsigned int exit_nr)
+{
+ int r = RESUME_HOST;
+
+ /* update before a new last_exit_type is rewritten */
+ kvmppc_update_timing_stats(vcpu);
+
+ /* restart interrupts if they were meant for the host */
+ kvmppc_restart_interrupt(vcpu, exit_nr);
local_irq_enable();
--
1.6.0.2
^ permalink raw reply related
* [PATCH 37/37] KVM: PPC: booke: Reinject performance monitor interrupts
From: Alexander Graf @ 2012-02-24 14:26 UTC (permalink / raw)
To: kvm-ppc; +Cc: Scott Wood, linuxppc-dev, kvm
In-Reply-To: <1330093591-19523-1-git-send-email-agraf@suse.de>
When we get a performance monitor interrupt, we need to make sure that
the host receives it. So reinject it like we reinject the other host
destined interrupts.
Signed-off-by: Alexander Graf <agraf@suse.de>
---
arch/powerpc/include/asm/hw_irq.h | 1 +
arch/powerpc/kvm/booke.c | 3 +++
2 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/include/asm/hw_irq.h b/arch/powerpc/include/asm/hw_irq.h
index bb712c9..904e66c 100644
--- a/arch/powerpc/include/asm/hw_irq.h
+++ b/arch/powerpc/include/asm/hw_irq.h
@@ -12,6 +12,7 @@
#include <asm/processor.h>
extern void timer_interrupt(struct pt_regs *);
+extern void performance_monitor_exception(struct pt_regs *regs);
#ifdef CONFIG_PPC64
#include <asm/paca.h>
diff --git a/arch/powerpc/kvm/booke.c b/arch/powerpc/kvm/booke.c
index 709fd45..c391357 100644
--- a/arch/powerpc/kvm/booke.c
+++ b/arch/powerpc/kvm/booke.c
@@ -630,6 +630,9 @@ static void kvmppc_restart_interrupt(struct kvm_vcpu *vcpu,
case BOOKE_INTERRUPT_MACHINE_CHECK:
/* FIXME */
break;
+ case BOOKE_INTERRUPT_PERFORMANCE_MONITOR:
+ performance_monitor_exception(®s);
+ break;
}
}
--
1.6.0.2
^ permalink raw reply related
* Re: [PATCH 00/14] DMA-mapping framework redesign preparation
From: Arnd Bergmann @ 2012-02-24 15:48 UTC (permalink / raw)
To: Marek Szyprowski
Cc: linux-arch, Stephen Rothwell, linux-alpha, linux-ia64,
Jonathan Corbet, linux-sh, x86, Andrzej Pietrasiewicz,
linux-kernel, linaro-mm-sig, linux-mm, Kyungmin Park, linux-mips,
microblaze-uclinux, sparclinux, Thomas Gleixner, linuxppc-dev,
Andrew Morton, linux-arm-kernel, discuss
In-Reply-To: <1324643253-3024-1-git-send-email-m.szyprowski@samsung.com>
On Friday 23 December 2011, Marek Szyprowski wrote:
> The solution we found is to introduce a new public dma mapping functions
> with additional attributes argument: dma_alloc_attrs and
> dma_free_attrs(). This way all different kinds of architecture specific
> buffer mappings can be hidden behind the attributes without the need of
> creating several versions of dma_alloc_ function.
Since the patches are now in linux-next, we should make sure that they
can actually get merged into 3.4.
I've looked at all the patches again and found them to be straightforward
and helpful, I hope we can get them merged next time. Please add my
Reviewed-by: Arnd Bergmann <arnd@arndb.de>
^ permalink raw reply
* [PATCH] sparsemem/bootmem: catch greater than section size allocations
From: Nishanth Aravamudan @ 2012-02-24 19:33 UTC (permalink / raw)
To: Andrew Morton
Cc: Anton Blanchard, Dave Hansen, linux-mm, Paul Mackerras,
Robert Jennings, linuxppc-dev
While testing AMS (Active Memory Sharing) / CMO (Cooperative Memory
Overcommit) on powerpc, we tripped the following:
kernel BUG at mm/bootmem.c:483!
cpu 0x0: Vector: 700 (Program Check) at [c000000000c03940]
pc: c000000000a62bd8: .alloc_bootmem_core+0x90/0x39c
lr: c000000000a64bcc: .sparse_early_usemaps_alloc_node+0x84/0x29c
sp: c000000000c03bc0
msr: 8000000000021032
current = 0xc000000000b0cce0
paca = 0xc000000001d80000
pid = 0, comm = swapper
kernel BUG at mm/bootmem.c:483!
enter ? for help
[c000000000c03c80] c000000000a64bcc
.sparse_early_usemaps_alloc_node+0x84/0x29c
[c000000000c03d50] c000000000a64f10 .sparse_init+0x12c/0x28c
[c000000000c03e20] c000000000a474f4 .setup_arch+0x20c/0x294
[c000000000c03ee0] c000000000a4079c .start_kernel+0xb4/0x460
[c000000000c03f90] c000000000009670 .start_here_common+0x1c/0x2c
This is
BUG_ON(limit && goal + size > limit);
and after some debugging, it seems that
goal = 0x7ffff000000
limit = 0x80000000000
and sparse_early_usemaps_alloc_node ->
sparse_early_usemaps_alloc_pgdat_section -> alloc_bootmem_section calls
return alloc_bootmem_section(usemap_size() * count, section_nr);
This is on a system with 8TB available via the AMS pool, and as a quirk
of AMS in firmware, all of that memory shows up in node 0. So, we end up
with an allocation that will fail the goal/limit constraints. In theory,
we could "fall-back" to alloc_bootmem_node() in
sparse_early_usemaps_alloc_node(), but since we actually have HOTREMOVE
defined, we'll BUG_ON() instead. A simple solution appears to be to
disable the limit check if the size of the allocation in
alloc_bootmem_secition exceeds the section size.
Signed-off-by: Nishanth Aravamudan <nacc@us.ibm.com>
Cc: Dave Hansen <haveblue@us.ibm.com>
Cc: Anton Blanchard <anton@au1.ibm.com>
Cc: Paul Mackerras <paulus@samba.org>
Cc: Ben Herrenschmidt <benh@kernel.crashing.org>
Cc: Robert Jennings <rcj@linux.vnet.ibm.com>
Cc: linux-mm@kvack.org
Cc: linuxppc-dev@lists.ozlabs.org
---
include/linux/mmzone.h | 2 ++
mm/bootmem.c | 5 ++++-
2 files changed, 6 insertions(+), 1 deletions(-)
diff --git a/include/linux/mmzone.h b/include/linux/mmzone.h
index 650ba2f..4176834 100644
--- a/include/linux/mmzone.h
+++ b/include/linux/mmzone.h
@@ -967,6 +967,8 @@ static inline unsigned long early_pfn_to_nid(unsigned long pfn)
* PA_SECTION_SHIFT physical address to/from section number
* PFN_SECTION_SHIFT pfn to/from section number
*/
+#define BYTES_PER_SECTION (1UL << SECTION_SIZE_BITS)
+
#define SECTIONS_SHIFT (MAX_PHYSMEM_BITS - SECTION_SIZE_BITS)
#define PA_SECTION_SHIFT (SECTION_SIZE_BITS)
diff --git a/mm/bootmem.c b/mm/bootmem.c
index 668e94d..5cbbc76 100644
--- a/mm/bootmem.c
+++ b/mm/bootmem.c
@@ -770,7 +770,10 @@ void * __init alloc_bootmem_section(unsigned long size,
pfn = section_nr_to_pfn(section_nr);
goal = pfn << PAGE_SHIFT;
- limit = section_nr_to_pfn(section_nr + 1) << PAGE_SHIFT;
+ if (size > BYTES_PER_SECTION)
+ limit = 0;
+ else
+ limit = section_nr_to_pfn(section_nr + 1) << PAGE_SHIFT;
bdata = &bootmem_node_data[early_pfn_to_nid(pfn)];
return alloc_bootmem_core(bdata, size, SMP_CACHE_BYTES, goal, limit);
--
1.7.5.4
^ permalink raw reply related
* Re: warnings from drivers/tty/ehv_bytechan.c
From: gregkh @ 2012-02-24 21:50 UTC (permalink / raw)
To: Tabi Timur-B04825; +Cc: Stephen Rothwell, ppc-dev
In-Reply-To: <4F424985.2020706@freescale.com>
On Mon, Feb 20, 2012 at 01:24:22PM +0000, Tabi Timur-B04825 wrote:
> Stephen Rothwell wrote:
> > console_initcall() is not defined for modules.
>
> Hmmm... the patch you posted is a good short-term fix, but I wonder if
> makes sense for the driver to support modules at all. I have this in the
> driver:
>
> #include <linux/module.h>
> ...
> module_init(ehv_bc_init);
> module_exit(ehv_bc_exit);
>
> although to be honest, I can't remember the last time I tried to compile
> it as a module.
>
> The problem stems from the fact that it's a console driver *and* a tty
> driver. It makes sense that a tty driver can be compiled as a module, but
> not a console driver.
>
> So Greg, can I do something like this:
>
> #ifdef MODULE
> module_initcall(ehv_bc_console_init)
> #else
> console_initcall(ehv_bc_console_init);
> #endif
Sure, something like that is fine, but if the code really can't be a
module, why not just fix the Kconfig file to enforce this properly
instead?
thanks,
greg k-h
^ permalink raw reply
* Re: warnings from drivers/tty/ehv_bytechan.c
From: Timur Tabi @ 2012-02-24 22:00 UTC (permalink / raw)
To: gregkh@linuxfoundation.org; +Cc: Stephen Rothwell, ppc-dev
In-Reply-To: <20120224215008.GB25330@kroah.com>
gregkh@linuxfoundation.org wrote:
> Sure, something like that is fine, but if the code really can't be a
> module, why not just fix the Kconfig file to enforce this properly
> instead?
That's the simplest approach, for use. The TTY portion of the driver can
be used as a module. Is there any real value in loading a TTY driver as a
module? In this case, the console support for byte channels would not be
available.
--
Timur Tabi
Linux kernel developer at Freescale
^ permalink raw reply
* Re: warnings from drivers/tty/ehv_bytechan.c
From: gregkh @ 2012-02-24 22:06 UTC (permalink / raw)
To: Timur Tabi; +Cc: Stephen Rothwell, ppc-dev
In-Reply-To: <4F48086C.5010407@freescale.com>
On Fri, Feb 24, 2012 at 04:00:12PM -0600, Timur Tabi wrote:
> gregkh@linuxfoundation.org wrote:
> > Sure, something like that is fine, but if the code really can't be a
> > module, why not just fix the Kconfig file to enforce this properly
> > instead?
>
> That's the simplest approach, for use. The TTY portion of the driver can
> be used as a module. Is there any real value in loading a TTY driver as a
> module?
Depends on the hardware it supports :)
> In this case, the console support for byte channels would not be
> available.
Then it doesn't make sense, right?
thanks,
greg k-h
^ permalink raw reply
* Re: warnings from drivers/tty/ehv_bytechan.c
From: Timur Tabi @ 2012-02-24 22:15 UTC (permalink / raw)
To: gregkh@linuxfoundation.org; +Cc: Stephen Rothwell, ppc-dev
In-Reply-To: <20120224220623.GA29400@kroah.com>
gregkh@linuxfoundation.org wrote:
>> > That's the simplest approach, for use. The TTY portion of the driver can
>> > be used as a module. Is there any real value in loading a TTY driver as a
>> > module?
> Depends on the hardware it supports :)
>
>> > In this case, the console support for byte channels would not be
>> > available.
> Then it doesn't make sense, right?
I guess that's my question. Is there a real use case for having console
output go to the serial port, and TTY go to a byte channel? Even if you
wanted to do that, I supposed you don't need to load the byte channel
driver as a module to get that behavior.
Anyway, that's all academic. A more important question is: now that the
driver can't be compiled as a module, should I change module_init() to
something else (like device_initcall)?
Should I remove this line?
#include <linux/module.h>
--
Timur Tabi
Linux kernel developer at Freescale
^ permalink raw reply
* Re: warnings from drivers/tty/ehv_bytechan.c
From: gregkh @ 2012-02-24 22:19 UTC (permalink / raw)
To: Timur Tabi; +Cc: Stephen Rothwell, ppc-dev
In-Reply-To: <4F480BE8.9080606@freescale.com>
On Fri, Feb 24, 2012 at 04:15:04PM -0600, Timur Tabi wrote:
> gregkh@linuxfoundation.org wrote:
> >> > That's the simplest approach, for use. The TTY portion of the driver can
> >> > be used as a module. Is there any real value in loading a TTY driver as a
> >> > module?
>
> > Depends on the hardware it supports :)
> >
> >> > In this case, the console support for byte channels would not be
> >> > available.
>
> > Then it doesn't make sense, right?
>
> I guess that's my question. Is there a real use case for having console
> output go to the serial port, and TTY go to a byte channel? Even if you
> wanted to do that, I supposed you don't need to load the byte channel
> driver as a module to get that behavior.
>
> Anyway, that's all academic. A more important question is: now that the
> driver can't be compiled as a module, should I change module_init() to
> something else (like device_initcall)?
>
> Should I remove this line?
>
> #include <linux/module.h>
No, no need to, leave it as-is if it builds properly.
greg k-h
^ permalink raw reply
* Re: [PATCH 09/24] PCI, powerpc: Register busn_res for root buses
From: Jesse Barnes @ 2012-02-24 22:24 UTC (permalink / raw)
To: Bjorn Helgaas
Cc: linux-arch, Tony Luck, linuxppc-dev, linux-kernel,
Dominik Brodowski, Linus Torvalds, Paul Mackerras, linux-pci,
Andrew Morton, Yinghai Lu
In-Reply-To: <CAErSpo7_WGjitDZz4XH+77f65Uz1ynd5_USN+D17D09Eux1iQQ@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 5202 bytes --]
On Thu, 23 Feb 2012 12:51:30 -0800
Bjorn Helgaas <bhelgaas@google.com> wrote:
> On Thu, Feb 23, 2012 at 12:25 PM, Jesse Barnes <jbarnes@virtuousgeek.org> wrote:
> > On Fri, 10 Feb 2012 08:35:58 +1100
> > Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote:
> >
> >> On Thu, 2012-02-09 at 11:24 -0800, Bjorn Helgaas wrote:
> >> > My point is that the interface between the arch and the PCI core
> >> > should be simply the arch telling the core "this is the range of bus
> >> > numbers you can use." If the firmware doesn't give you the HW limits,
> >> > that's the arch's problem. If you want to assume 0..255 are
> >> > available, again, that's the arch's decision.
> >> >
> >> > But the answer to the question "what bus numbers are available to me"
> >> > depends only on the host bridge HW configuration. It does not depend
> >> > on what pci_scan_child_bus() found. Therefore, I think we can come up
> >> > with a design where pci_bus_update_busn_res_end() is unnecessary.
> >>
> >> In an ideal world yes. In a world where there are reverse engineered
> >> platforms on which we aren't 100% sure how thing actually work under the
> >> hood and have the code just adapt on "what's there" (and try to fix it
> >> up -sometimes-), thinks can get a bit murky :-)
> >>
> >> But yes, I see your point. As for what is the "correct" setting that
> >> needs to be done so that the patch doesn't end up a regression for us,
> >> I'll have to dig into some ancient HW to dbl check a few things. I hope
> >> 0...255 will just work but I can't guarantee it.
> >>
> >> What I'll probably do is constraint the core to the values in
> >> hose->min/max, and update selected platforms to put 0..255 in there when
> >> I know for sure they can cope.
> >
> > But I think the point is, can't we intiialize the busn resource after
> > the first & last bus numbers have been determined? E.g. rather than
> > Yinghai's current:
> > + pci_bus_insert_busn_res(bus, hose->first_busno, hose->last_busno);
> > +
> > /* Get probe mode and perform scan */
> > mode = PCI_PROBE_NORMAL;
> > if (node && ppc_md.pci_probe_mode)
> > @@ -1742,8 +1744,11 @@ void __devinit pcibios_scan_phb(struct pci_controller *hose)
> > of_scan_bus(node, bus);
> > }
> >
> > - if (mode == PCI_PROBE_NORMAL)
> > + if (mode == PCI_PROBE_NORMAL) {
> > + pci_bus_update_busn_res_end(bus, 255);
> > hose->last_busno = bus->subordinate = pci_scan_child_bus(bus);
> > + pci_bus_update_busn_res_end(bus, bus->subordinate);
> > + }
> >
> > we'd have something more like:
> >
> > /* Get probe mode and perform scan */
> > mode = PCI_PROBE_NORMAL;
> > if (node && ppc_md.pci_probe_mode)
> > @@ -1742,8 +1744,11 @@ void __devinit pcibios_scan_phb(struct pci_controller *hose)
> > of_scan_bus(node, bus);
> > }
> >
> > if (mode == PCI_PROBE_NORMAL)
> > hose->last_busno = bus->subordinate = pci_scan_child_bus(bus);
> >
> > + pci_bus_insert_busn_res(bus, hose->first_busno, hose->last_busno);
> >
> > since we should have the final bus range by then? Setting the end to
> > 255 and then changing it again doesn't make sense; and definitely makes
> > the code hard to follow.
>
> I have two issues here:
>
> 1) hose->last_busno is currently the highest bus number found by
> pci_scan_child_bus(). If I understand correctly,
> pci_bus_insert_busn_res() is supposed to update the core's idea of the
> host bridge's bus number aperture. (Actually, I guess it just updates
> the *end* of the aperture, since we supply the start directly to
> pci_scan_root_bus()). The aperture and the highest bus number we
> found are not related, except that we should have:
>
> hose->first_busno <= bus->subordinate <= hose->last_busno
>
> If we set the aperture to [first_busno - last_busno], we artificially
> prevent some hotplug.
Oh true, we'll need to allocate any extra bus number space somehow so
that hot plug of bridges is possible in the future w/o renumbering
(until our glorious future when we can move resources on the fly by
stopping drivers).
>
> 2) We already have a way to add resources to a root bus: the
> pci_add_resource() used to add I/O port and MMIO apertures. I think
> it'd be a lot simpler to just use that same interface for the bus
> number aperture, e.g.,
>
> pci_add_resource(&resources, hose->io_space);
> pci_add_resource(&resources, hose->mem_space);
> pci_add_resource(&resources, hose->busnr_space);
> bus = pci_scan_root_bus(dev, next_busno, pci_ops, sysdata, &resources);
>
> This is actually a bit redundant, since "next_busno" should be the
> same as hose->busnr_space->start. So if we adopted this approach, we
> might want to eventually drop the "next_busno" argument.
Yeah that would be nice, the call would certainly make more sense that
way.
--
Jesse Barnes, Intel Open Source Technology Center
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: warnings from drivers/tty/ehv_bytechan.c
From: Scott Wood @ 2012-02-24 23:25 UTC (permalink / raw)
To: Timur Tabi; +Cc: gregkh@linuxfoundation.org, ppc-dev, Stephen Rothwell
In-Reply-To: <4F480BE8.9080606@freescale.com>
On 02/24/2012 04:15 PM, Timur Tabi wrote:
> gregkh@linuxfoundation.org wrote:
>>>> That's the simplest approach, for use. The TTY portion of the driver can
>>>> be used as a module. Is there any real value in loading a TTY driver as a
>>>> module?
>
>> Depends on the hardware it supports :)
>>
>>>> In this case, the console support for byte channels would not be
>>>> available.
>
>> Then it doesn't make sense, right?
>
> I guess that's my question. Is there a real use case for having console
> output go to the serial port, and TTY go to a byte channel?
Sure -- you could be using the byte channel for inter-partition
communication, or just not have enough serial ports for all of this
partition's needs.
It looks like the usual pattern is to have a separate kconfig for the
console part, and have that be a bool that depends on the tristate tty
driver being "y".
> Even if you
> wanted to do that, I supposed you don't need to load the byte channel
> driver as a module to get that behavior.
Right, though that could be said about all (most?) modules.
Probably not that important in this particular case, though. I can see
people wanting to use byte channel but not caring about console, and I
can see people wanting to build a generic kernel that supports byte
channels, but I don't think there's much overlap between the two.
-Scott
^ permalink raw reply
* Re: [PATCH 33/37] KVM: PPC: bookehv: remove unused code
From: Scott Wood @ 2012-02-24 23:31 UTC (permalink / raw)
To: Alexander Graf; +Cc: linuxppc-dev, kvm, kvm-ppc
In-Reply-To: <1330093591-19523-34-git-send-email-agraf@suse.de>
On 02/24/2012 08:26 AM, Alexander Graf wrote:
> There was some unused code in the exit code path that must have been
> a leftover from earlier iterations. While it did no hard, it's superfluous
> and thus should be removed.
s/hard/harm/ -- at that assumes exit timing wasn't enabled. :-)
>
> Signed-off-by: Alexander Graf <agraf@suse.de>
> ---
> arch/powerpc/kvm/bookehv_interrupts.S | 3 ---
> 1 files changed, 0 insertions(+), 3 deletions(-)
>
> diff --git a/arch/powerpc/kvm/bookehv_interrupts.S b/arch/powerpc/kvm/bookehv_interrupts.S
> index 021d087..b1c099b 100644
> --- a/arch/powerpc/kvm/bookehv_interrupts.S
> +++ b/arch/powerpc/kvm/bookehv_interrupts.S
> @@ -112,9 +112,6 @@
> * appropriate for the exception type).
> */
> cmpw r6, r8
> - .if \flags & NEED_EMU
> - lwz r9, KVM_LPID(r9)
> - .endif
> beq 1f
> mfmsr r7
> .if \srr0 != SPRN_MCSRR0 && \srr0 != SPRN_CSRR0
Can also remove "lwz r9, VCPU_KVM(r4)".
-Scott
^ permalink raw reply
* Re: [PATCH 35/37] KVM: PPC: booke: Support perfmon interrupts
From: Scott Wood @ 2012-02-24 23:33 UTC (permalink / raw)
To: Alexander Graf; +Cc: linuxppc-dev, kvm, kvm-ppc
In-Reply-To: <1330093591-19523-36-git-send-email-agraf@suse.de>
On 02/24/2012 08:26 AM, Alexander Graf wrote:
> When during guest context we get a performance monitor interrupt, we
> currently bail out and oops. Let's route it to its correct handler
> instead.
>
> Signed-off-by: Alexander Graf <agraf@suse.de>
> ---
> arch/powerpc/kvm/booke.c | 4 ++++
> 1 files changed, 4 insertions(+), 0 deletions(-)
>
> diff --git a/arch/powerpc/kvm/booke.c b/arch/powerpc/kvm/booke.c
> index 7adef28..423701b 100644
> --- a/arch/powerpc/kvm/booke.c
> +++ b/arch/powerpc/kvm/booke.c
> @@ -677,6 +677,10 @@ int kvmppc_handle_exit(struct kvm_run *run, struct kvm_vcpu *vcpu,
> r = RESUME_GUEST;
> break;
>
> + case BOOKE_INTERRUPT_PERFORMANCE_MONITOR:
> + r = RESUME_GUEST;
> + break;
> +
> case BOOKE_INTERRUPT_HV_PRIV:
> r = emulation_exit(run, vcpu);
> break;
Why do we need to call timer_interrupt() explicitly, but can rely on
automatic retriggering for perfmon?
-Scott
^ permalink raw reply
* Re: [PATCH 36/37] KVM: PPC: booke: expose guest registers on irq reinject
From: Scott Wood @ 2012-02-24 23:40 UTC (permalink / raw)
To: Alexander Graf; +Cc: linuxppc-dev, kvm, kvm-ppc
In-Reply-To: <1330093591-19523-37-git-send-email-agraf@suse.de>
On 02/24/2012 08:26 AM, Alexander Graf wrote:
> +static void kvmppc_fill_pt_regs(struct kvm_vcpu *vcpu, struct pt_regs *regs)
> {
> - int r = RESUME_HOST;
> + int i;
>
> - /* update before a new last_exit_type is rewritten */
> - kvmppc_update_timing_stats(vcpu);
> + for (i = 0; i < 32; i++)
> + regs->gpr[i] = kvmppc_get_gpr(vcpu, i);
> + regs->nip = vcpu->arch.pc;
> + regs->msr = vcpu->arch.shared->msr;
> + regs->ctr = vcpu->arch.ctr;
> + regs->link = vcpu->arch.lr;
> + regs->xer = kvmppc_get_xer(vcpu);
> + regs->ccr = kvmppc_get_cr(vcpu);
> + regs->dar = get_guest_dear(vcpu);
> + regs->dsisr = get_guest_esr(vcpu);
> +}
How much overhead does this add to every interrupt? Can't we keep this
to the minimum that perf cares about?
> +
> +static void kvmppc_restart_interrupt(struct kvm_vcpu *vcpu,
> + unsigned int exit_nr)
> +{
> + struct pt_regs regs = *current->thread.regs;
>
> + kvmppc_fill_pt_regs(vcpu, ®s);
Why are you copying out of current->thread.regs? That's old junk data,
set by some previous exception and possibly overwritten since.
-Scott
^ permalink raw reply
* [PATCH] powerpc/prom: bump up maximum size of properties
From: Nishanth Aravamudan @ 2012-02-25 0:23 UTC (permalink / raw)
To: benh; +Cc: linuxppc-dev, Anton Blanchard, Paul Mackerras, Robert Jennings
On a 16TB system (using AMS/CMO), I get:
WARNING: ignoring large property [/ibm,dynamic-reconfiguration-memory] ibm,dynamic-memory length 0x000000000017ffec
and significantly less memory is thus shown to the partition. As far as
I can tell, the constant used is arbitrary, but bump it up to 2MB, which
covers the above property (approximately 1.5MB).
With this patch, the kernel does see all of the system memory on the
16TB system.
Signed-off-by: Nishanth Aravamudan <nacc@us.ibm.com>
Cc: Anton Blanchard <anton@au1.ibm.com>
Cc: Paul Mackerras <paulus@samba.org>
Cc: Robert Jennings <rcj@linux.vnet.ibm.com>
Cc: linuxppc-dev@lists.ozlabs.org
---
arch/powerpc/kernel/prom_init.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/powerpc/kernel/prom_init.c b/arch/powerpc/kernel/prom_init.c
index eca626e..0bf0ccc 100644
--- a/arch/powerpc/kernel/prom_init.c
+++ b/arch/powerpc/kernel/prom_init.c
@@ -53,7 +53,7 @@
* ensure that we don't lose things like the interrupt-map property
* on a PCI-PCI bridge.
*/
-#define MAX_PROPERTY_LENGTH (1UL * 1024 * 1024)
+#define MAX_PROPERTY_LENGTH (2UL * 1024 * 1024)
/*
* Eventually bump that one up
--
1.7.5.4
^ permalink raw reply related
* Re: [PATCH 09/24] PCI, powerpc: Register busn_res for root buses
From: Yinghai Lu @ 2012-02-25 7:47 UTC (permalink / raw)
To: Jesse Barnes
Cc: linux-arch, Tony Luck, linuxppc-dev, linux-kernel,
Dominik Brodowski, Paul Mackerras, linux-pci, Bjorn Helgaas,
Andrew Morton, Linus Torvalds
In-Reply-To: <20120224142430.58f5e5ef@jbarnes-desktop>
On Fri, Feb 24, 2012 at 2:24 PM, Jesse Barnes <jbarnes@virtuousgeek.org> wr=
ote:
> On Thu, 23 Feb 2012 12:51:30 -0800
> Bjorn Helgaas <bhelgaas@google.com> wrote:
>> 2) We already have a way to add resources to a root bus: the
>> pci_add_resource() used to add I/O port and MMIO apertures. =A0I think
>> it'd be a lot simpler to just use that same interface for the bus
>> number aperture, e.g.,
>>
>> =A0 =A0 pci_add_resource(&resources, hose->io_space);
>> =A0 =A0 pci_add_resource(&resources, hose->mem_space);
>> =A0 =A0 pci_add_resource(&resources, hose->busnr_space);
>> =A0 =A0 bus =3D pci_scan_root_bus(dev, next_busno, pci_ops, sysdata, &re=
sources);
>>
>> This is actually a bit redundant, since "next_busno" should be the
>> same as hose->busnr_space->start. =A0So if we adopted this approach, we
>> might want to eventually drop the "next_busno" argument.
>
> Yeah that would be nice, the call would certainly make more sense that
> way.
no, I don't think so.
using pci_add_resource will need to create dummy resource abut bus range.
there is lots of pci_scan_root_bus(), and those user does not bus end
yet before scan.
so could just hide pci_insert_busn_res in pci_scan_root_bus, and
update busn_res end there.
other arch like x86, ia64, powerpc, sparc, will insert exact bus range
between pci_create_root_bus and
pci_scan_child_bus, will not need to update busn_res end.
please check v7 of this patchset.
git://git.kernel.org/pub/scm/linux/kernel/git/yinghai/linux-yinghai.gi=
t
for-pci-busn-alloc
It should be clean and have minimum lines of change.
Thanks
Yinghai
^ permalink raw reply
* Re: [PATCH 35/37] KVM: PPC: booke: Support perfmon interrupts
From: Alexander Graf @ 2012-02-26 11:58 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev, kvm, kvm-ppc
In-Reply-To: <4F481E66.8010408@freescale.com>
On 25.02.2012, at 00:33, Scott Wood wrote:
> On 02/24/2012 08:26 AM, Alexander Graf wrote:
>> When during guest context we get a performance monitor interrupt, we
>> currently bail out and oops. Let's route it to its correct handler
>> instead.
>>=20
>> Signed-off-by: Alexander Graf <agraf@suse.de>
>> ---
>> arch/powerpc/kvm/booke.c | 4 ++++
>> 1 files changed, 4 insertions(+), 0 deletions(-)
>>=20
>> diff --git a/arch/powerpc/kvm/booke.c b/arch/powerpc/kvm/booke.c
>> index 7adef28..423701b 100644
>> --- a/arch/powerpc/kvm/booke.c
>> +++ b/arch/powerpc/kvm/booke.c
>> @@ -677,6 +677,10 @@ int kvmppc_handle_exit(struct kvm_run *run, =
struct kvm_vcpu *vcpu,
>> r =3D RESUME_GUEST;
>> break;
>>=20
>> + case BOOKE_INTERRUPT_PERFORMANCE_MONITOR:
>> + r =3D RESUME_GUEST;
>> + break;
>> +
>> case BOOKE_INTERRUPT_HV_PRIV:
>> r =3D emulation_exit(run, vcpu);
>> break;
>=20
> Why do we need to call timer_interrupt() explicitly, but can rely on
> automatic retriggering for perfmon?
We don't rely on automatic retriggering for perfmon. There are 2 =
different places where we need to handle an incoming exit code - the =
"reinject" code path and the "big switch over all exits" code path. This =
one deals with the latter.
Alex
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox