[PATCH 0/4 v2] KVM :PPC: Userspace Debug support
From: Bharat Bhushan bharat.bhus...@freescale.com This patchset adds the userspace debug support for booke/bookehv. this is tested on powerpc e500v2/e500mc devices. v1-v2 - Debug registers are save/restore in vcpu_put/vcpu_get. Earlier the debug registers are saved/restored in guest entry/exit Bharat Bhushan (4): Added ONE_REG interface for debug instruction KVM: PPC: debug stub interface parameter defined Rename EMULATE_DO_PAPR to EMULATE_EXIT_USER KVM: PPC: Add userspace debug stub support Documentation/virtual/kvm/api.txt |1 + arch/powerpc/include/asm/kvm_book3s.h |2 + arch/powerpc/include/asm/kvm_booke.h |2 + arch/powerpc/include/asm/kvm_host.h | 10 ++ arch/powerpc/include/asm/kvm_ppc.h|2 +- arch/powerpc/include/uapi/asm/kvm.h | 41 ++ arch/powerpc/kvm/book3s.c | 12 ++ arch/powerpc/kvm/book3s_emulate.c |4 +- arch/powerpc/kvm/book3s_pr.c |4 +- arch/powerpc/kvm/booke.c | 252 +++-- arch/powerpc/kvm/e500_emulate.c | 10 ++ arch/powerpc/kvm/powerpc.c|6 - 12 files changed, 323 insertions(+), 23 deletions(-) -- 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 1/4 v2] Added ONE_REG interface for debug instruction
This patch adds the one_reg interface to get the special instruction
to be used for setting software breakpoint from userspace.
Signed-off-by: Bharat Bhushan bharat.bhus...@freescale.com
---
v2:
- Corrected trap tw always opcode.
Documentation/virtual/kvm/api.txt |1 +
arch/powerpc/include/asm/kvm_book3s.h |2 ++
arch/powerpc/include/asm/kvm_booke.h |2 ++
arch/powerpc/include/uapi/asm/kvm.h |4
arch/powerpc/kvm/book3s.c |6 ++
arch/powerpc/kvm/booke.c |6 ++
6 files changed, 21 insertions(+), 0 deletions(-)
diff --git a/Documentation/virtual/kvm/api.txt
b/Documentation/virtual/kvm/api.txt
index cce500a..dbfcc04 100644
--- a/Documentation/virtual/kvm/api.txt
+++ b/Documentation/virtual/kvm/api.txt
@@ -1766,6 +1766,7 @@ registers, find a list below:
PPC | KVM_REG_PPC_TSR | 32
PPC | KVM_REG_PPC_OR_TSR | 32
PPC | KVM_REG_PPC_CLEAR_TSR| 32
+ PPC | KVM_REG_PPC_DEBUG_INST| 32
4.69 KVM_GET_ONE_REG
diff --git a/arch/powerpc/include/asm/kvm_book3s.h
b/arch/powerpc/include/asm/kvm_book3s.h
index 5a56e1c..bc81842 100644
--- a/arch/powerpc/include/asm/kvm_book3s.h
+++ b/arch/powerpc/include/asm/kvm_book3s.h
@@ -458,6 +458,8 @@ static inline bool kvmppc_critical_section(struct kvm_vcpu
*vcpu)
#define OSI_SC_MAGIC_R40x77810F9B
#define INS_DCBZ 0x7c0007ec
+/* TO = 31 for unconditional trap */
+#define INS_TW 0x7fe8
/* LPIDs we support with this build -- runtime limit may be lower */
#define KVMPPC_NR_LPIDS(LPID_RSVD + 1)
diff --git a/arch/powerpc/include/asm/kvm_booke.h
b/arch/powerpc/include/asm/kvm_booke.h
index b7cd335..d3c1eb3 100644
--- a/arch/powerpc/include/asm/kvm_booke.h
+++ b/arch/powerpc/include/asm/kvm_booke.h
@@ -26,6 +26,8 @@
/* LPIDs we support with this build -- runtime limit may be lower */
#define KVMPPC_NR_LPIDS64
+#define KVMPPC_INST_EHPRIV 0x7c00021c
+
static inline void kvmppc_set_gpr(struct kvm_vcpu *vcpu, int num, ulong val)
{
vcpu-arch.gpr[num] = val;
diff --git a/arch/powerpc/include/uapi/asm/kvm.h
b/arch/powerpc/include/uapi/asm/kvm.h
index ef072b1..c2ff99c 100644
--- a/arch/powerpc/include/uapi/asm/kvm.h
+++ b/arch/powerpc/include/uapi/asm/kvm.h
@@ -422,4 +422,8 @@ struct kvm_get_htab_header {
#define KVM_REG_PPC_CLEAR_TSR (KVM_REG_PPC | KVM_REG_SIZE_U32 | 0x88)
#define KVM_REG_PPC_TCR(KVM_REG_PPC | KVM_REG_SIZE_U32 | 0x89)
#define KVM_REG_PPC_TSR(KVM_REG_PPC | KVM_REG_SIZE_U32 | 0x8a)
+
+/* Debugging: Special instruction for software breakpoint */
+#define KVM_REG_PPC_DEBUG_INST (KVM_REG_PPC | KVM_REG_SIZE_U32 | 0x8b)
+
#endif /* __LINUX_KVM_POWERPC_H */
diff --git a/arch/powerpc/kvm/book3s.c b/arch/powerpc/kvm/book3s.c
index a4b6452..975a401 100644
--- a/arch/powerpc/kvm/book3s.c
+++ b/arch/powerpc/kvm/book3s.c
@@ -530,6 +530,12 @@ int kvm_vcpu_ioctl_get_one_reg(struct kvm_vcpu *vcpu,
struct kvm_one_reg *reg)
val = get_reg_val(reg-id, vcpu-arch.vscr.u[3]);
break;
#endif /* CONFIG_ALTIVEC */
+ case KVM_REG_PPC_DEBUG_INST: {
+ u32 opcode = INS_TW;
+ r = copy_to_user((u32 __user *)(long)reg-addr,
+opcode, sizeof(u32));
+ break;
+ }
default:
r = -EINVAL;
break;
diff --git a/arch/powerpc/kvm/booke.c b/arch/powerpc/kvm/booke.c
index 8b553c0..a41cd6d 100644
--- a/arch/powerpc/kvm/booke.c
+++ b/arch/powerpc/kvm/booke.c
@@ -1448,6 +1448,12 @@ int kvm_vcpu_ioctl_get_one_reg(struct kvm_vcpu *vcpu,
struct kvm_one_reg *reg)
case KVM_REG_PPC_TSR:
r = put_user(vcpu-arch.tsr, (u32 __user *)(long)reg-addr);
break;
+ case KVM_REG_PPC_DEBUG_INST: {
+ u32 opcode = KVMPPC_INST_EHPRIV;
+ r = copy_to_user((u32 __user *)(long)reg-addr,
+opcode, sizeof(u32));
+ break;
+ }
default:
break;
}
--
1.7.0.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 2/4 v2] KVM: PPC: debug stub interface parameter defined
From: Bharat Bhushan bharat.bhus...@freescale.com
This patch defines the interface parameter for KVM_SET_GUEST_DEBUG
ioctl support. Follow up patches will use this for setting up
hardware breakpoints, watchpoints and software breakpoints.
Also kvm_arch_vcpu_ioctl_set_guest_debug() is brought one level below.
This is because I am not sure what is required for book3s. So this ioctl
behaviour will not change for book3s.
Signed-off-by: Bharat Bhushan bharat.bhus...@freescale.com
---
v2:
- No Change
arch/powerpc/include/uapi/asm/kvm.h | 23 +++
arch/powerpc/kvm/book3s.c |6 ++
arch/powerpc/kvm/booke.c|6 ++
arch/powerpc/kvm/powerpc.c |6 --
4 files changed, 35 insertions(+), 6 deletions(-)
diff --git a/arch/powerpc/include/uapi/asm/kvm.h
b/arch/powerpc/include/uapi/asm/kvm.h
index c2ff99c..15f9a00 100644
--- a/arch/powerpc/include/uapi/asm/kvm.h
+++ b/arch/powerpc/include/uapi/asm/kvm.h
@@ -272,8 +272,31 @@ struct kvm_debug_exit_arch {
/* for KVM_SET_GUEST_DEBUG */
struct kvm_guest_debug_arch {
+ struct {
+ /* H/W breakpoint/watchpoint address */
+ __u64 addr;
+ /*
+* Type denotes h/w breakpoint, read watchpoint, write
+* watchpoint or watchpoint (both read and write).
+*/
+#define KVMPPC_DEBUG_NOTYPE0x0
+#define KVMPPC_DEBUG_BREAKPOINT(1UL 1)
+#define KVMPPC_DEBUG_WATCH_WRITE (1UL 2)
+#define KVMPPC_DEBUG_WATCH_READ(1UL 3)
+ __u32 type;
+ __u32 reserved;
+ } bp[16];
};
+/* Debug related defines */
+/*
+ * kvm_guest_debug-control is a 32 bit field. The lower 16 bits are generic
+ * and upper 16 bits are architecture specific. Architecture specific defines
+ * that ioctl is for setting hardware breakpoint or software breakpoint.
+ */
+#define KVM_GUESTDBG_USE_SW_BP 0x0001
+#define KVM_GUESTDBG_USE_HW_BP 0x0002
+
/* definition of registers in kvm_run */
struct kvm_sync_regs {
};
diff --git a/arch/powerpc/kvm/book3s.c b/arch/powerpc/kvm/book3s.c
index 975a401..cb85d73 100644
--- a/arch/powerpc/kvm/book3s.c
+++ b/arch/powerpc/kvm/book3s.c
@@ -613,6 +613,12 @@ int kvm_arch_vcpu_ioctl_translate(struct kvm_vcpu *vcpu,
return 0;
}
+int kvm_arch_vcpu_ioctl_set_guest_debug(struct kvm_vcpu *vcpu,
+ struct kvm_guest_debug *dbg)
+{
+ return -EINVAL;
+}
+
void kvmppc_decrementer_func(unsigned long data)
{
struct kvm_vcpu *vcpu = (struct kvm_vcpu *)data;
diff --git a/arch/powerpc/kvm/booke.c b/arch/powerpc/kvm/booke.c
index a41cd6d..1de93a8 100644
--- a/arch/powerpc/kvm/booke.c
+++ b/arch/powerpc/kvm/booke.c
@@ -1527,6 +1527,12 @@ int kvm_vcpu_ioctl_set_one_reg(struct kvm_vcpu *vcpu,
struct kvm_one_reg *reg)
return r;
}
+int kvm_arch_vcpu_ioctl_set_guest_debug(struct kvm_vcpu *vcpu,
+struct kvm_guest_debug *dbg)
+{
+ return -EINVAL;
+}
+
int kvm_arch_vcpu_ioctl_get_fpu(struct kvm_vcpu *vcpu, struct kvm_fpu *fpu)
{
return -ENOTSUPP;
diff --git a/arch/powerpc/kvm/powerpc.c b/arch/powerpc/kvm/powerpc.c
index 934413c..4c94ca9 100644
--- a/arch/powerpc/kvm/powerpc.c
+++ b/arch/powerpc/kvm/powerpc.c
@@ -532,12 +532,6 @@ void kvm_arch_vcpu_put(struct kvm_vcpu *vcpu)
#endif
}
-int kvm_arch_vcpu_ioctl_set_guest_debug(struct kvm_vcpu *vcpu,
-struct kvm_guest_debug *dbg)
-{
- return -EINVAL;
-}
-
static void kvmppc_complete_dcr_load(struct kvm_vcpu *vcpu,
struct kvm_run *run)
{
--
1.7.0.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 3/4 v2] Rename EMULATE_DO_PAPR to EMULATE_EXIT_USER
From: Bharat Bhushan bharat.bhus...@freescale.com
Instruction emulation return EMULATE_DO_PAPR when it requires
exit to userspace on book3s. Similar return is required
for booke. EMULATE_DO_PAPR reads out to be confusing so it is
renamed to EMULATE_EXIT_USER.
Signed-off-by: Bharat Bhushan bharat.bhus...@freescale.com
---
v2:
- moved run-exit_reason and vcpu-arch.hcall_needed to emulator.
arch/powerpc/include/asm/kvm_ppc.h |2 +-
arch/powerpc/kvm/book3s_emulate.c |4 +++-
arch/powerpc/kvm/book3s_pr.c |4 +---
3 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/arch/powerpc/include/asm/kvm_ppc.h
b/arch/powerpc/include/asm/kvm_ppc.h
index 44a657a..8b81468 100644
--- a/arch/powerpc/include/asm/kvm_ppc.h
+++ b/arch/powerpc/include/asm/kvm_ppc.h
@@ -44,7 +44,7 @@ enum emulation_result {
EMULATE_DO_DCR, /* kvm_run filled with DCR request */
EMULATE_FAIL, /* can't emulate this instruction */
EMULATE_AGAIN,/* something went wrong. go again */
- EMULATE_DO_PAPR, /* kvm_run filled with PAPR request */
+ EMULATE_EXIT_USER,/* emulation requires exit to user-space */
};
extern int kvmppc_vcpu_run(struct kvm_run *kvm_run, struct kvm_vcpu *vcpu);
diff --git a/arch/powerpc/kvm/book3s_emulate.c
b/arch/powerpc/kvm/book3s_emulate.c
index 836c569..1f6344c 100644
--- a/arch/powerpc/kvm/book3s_emulate.c
+++ b/arch/powerpc/kvm/book3s_emulate.c
@@ -194,7 +194,9 @@ int kvmppc_core_emulate_op(struct kvm_run *run, struct
kvm_vcpu *vcpu,
run-papr_hcall.args[i] = gpr;
}
- emulated = EMULATE_DO_PAPR;
+ run-exit_reason = KVM_EXIT_PAPR_HCALL;
+ vcpu-arch.hcall_needed = 1;
+ emulated = EMULATE_EXIT_USER;
break;
}
#endif
diff --git a/arch/powerpc/kvm/book3s_pr.c b/arch/powerpc/kvm/book3s_pr.c
index 73ed11c..2e8bd53 100644
--- a/arch/powerpc/kvm/book3s_pr.c
+++ b/arch/powerpc/kvm/book3s_pr.c
@@ -760,9 +760,7 @@ program_interrupt:
run-exit_reason = KVM_EXIT_MMIO;
r = RESUME_HOST_NV;
break;
- case EMULATE_DO_PAPR:
- run-exit_reason = KVM_EXIT_PAPR_HCALL;
- vcpu-arch.hcall_needed = 1;
+ case EMULATE_EXIT_USER:
r = RESUME_HOST_NV;
break;
default:
--
1.7.0.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 4/4 v2] KVM: PPC: Add userspace debug stub support
From: Bharat Bhushan bharat.bhus...@freescale.com
This patch adds the debug stub support on booke/bookehv.
Now QEMU debug stub can use hw breakpoint, watchpoint and
software breakpoint to debug guest.
Debug registers are saved/restored on vcpu_put()/vcpu_get().
Also the debug registers are saved restored only if guest is using
debug resources.
Signed-off-by: Bharat Bhushan bharat.bhus...@freescale.com
---
v2:
- save/restore in vcpu_get()/vcpu_put()
- some more minor cleanup based on review comments.
arch/powerpc/include/asm/kvm_host.h | 10 ++
arch/powerpc/include/uapi/asm/kvm.h | 22 +++-
arch/powerpc/kvm/booke.c| 252 ---
arch/powerpc/kvm/e500_emulate.c | 10 ++
4 files changed, 272 insertions(+), 22 deletions(-)
diff --git a/arch/powerpc/include/asm/kvm_host.h
b/arch/powerpc/include/asm/kvm_host.h
index f4ba881..8571952 100644
--- a/arch/powerpc/include/asm/kvm_host.h
+++ b/arch/powerpc/include/asm/kvm_host.h
@@ -504,7 +504,17 @@ struct kvm_vcpu_arch {
u32 mmucfg;
u32 epr;
u32 crit_save;
+ /* guest debug registers*/
struct kvmppc_booke_debug_reg dbg_reg;
+ /* shadow debug registers */
+ struct kvmppc_booke_debug_reg shadow_dbg_reg;
+ /* host debug registers*/
+ struct kvmppc_booke_debug_reg host_dbg_reg;
+ /*
+* Flag indicating that debug registers are used by guest
+* and requires save restore.
+ */
+ bool debug_save_restore;
#endif
gpa_t paddr_accessed;
gva_t vaddr_accessed;
diff --git a/arch/powerpc/include/uapi/asm/kvm.h
b/arch/powerpc/include/uapi/asm/kvm.h
index 15f9a00..d7ce449 100644
--- a/arch/powerpc/include/uapi/asm/kvm.h
+++ b/arch/powerpc/include/uapi/asm/kvm.h
@@ -25,6 +25,7 @@
/* Select powerpc specific features in linux/kvm.h */
#define __KVM_HAVE_SPAPR_TCE
#define __KVM_HAVE_PPC_SMT
+#define __KVM_HAVE_GUEST_DEBUG
struct kvm_regs {
__u64 pc;
@@ -267,7 +268,24 @@ struct kvm_fpu {
__u64 fpr[32];
};
+/*
+ * Defines for h/w breakpoint, watchpoint (read, write or both) and
+ * software breakpoint.
+ * These are used as type in KVM_SET_GUEST_DEBUG ioctl and status
+ * for KVM_DEBUG_EXIT.
+ */
+#define KVMPPC_DEBUG_NONE 0x0
+#define KVMPPC_DEBUG_BREAKPOINT(1UL 1)
+#define KVMPPC_DEBUG_WATCH_WRITE (1UL 2)
+#define KVMPPC_DEBUG_WATCH_READ(1UL 3)
struct kvm_debug_exit_arch {
+ __u64 address;
+ /*
+* exiting to userspace because of h/w breakpoint, watchpoint
+* (read, write or both) and software breakpoint.
+*/
+ __u32 status;
+ __u32 reserved;
};
/* for KVM_SET_GUEST_DEBUG */
@@ -279,10 +297,6 @@ struct kvm_guest_debug_arch {
* Type denotes h/w breakpoint, read watchpoint, write
* watchpoint or watchpoint (both read and write).
*/
-#define KVMPPC_DEBUG_NOTYPE0x0
-#define KVMPPC_DEBUG_BREAKPOINT(1UL 1)
-#define KVMPPC_DEBUG_WATCH_WRITE (1UL 2)
-#define KVMPPC_DEBUG_WATCH_READ(1UL 3)
__u32 type;
__u32 reserved;
} bp[16];
diff --git a/arch/powerpc/kvm/booke.c b/arch/powerpc/kvm/booke.c
index 1de93a8..bf20056 100644
--- a/arch/powerpc/kvm/booke.c
+++ b/arch/powerpc/kvm/booke.c
@@ -133,6 +133,30 @@ static void kvmppc_vcpu_sync_fpu(struct kvm_vcpu *vcpu)
#endif
}
+static void kvmppc_vcpu_sync_debug(struct kvm_vcpu *vcpu)
+{
+ /* Synchronize guest's desire to get debug interrupts into shadow MSR */
+#ifndef CONFIG_KVM_BOOKE_HV
+ vcpu-arch.shadow_msr = ~MSR_DE;
+ vcpu-arch.shadow_msr |= vcpu-arch.shared-msr MSR_DE;
+#endif
+
+ /* Force enable debug interrupts when user space wants to debug */
+ if (vcpu-guest_debug) {
+#ifdef CONFIG_KVM_BOOKE_HV
+ /*
+* Since there is no shadow MSR, sync MSR_DE into the guest
+* visible MSR. Do not allow guest to change MSR[DE].
+*/
+ vcpu-arch.shared-msr |= MSR_DE;
+ mtspr(SPRN_MSRP, mfspr(SPRN_MSRP) | MSRP_DEP);
+#else
+ vcpu-arch.shadow_msr |= MSR_DE;
+ vcpu-arch.shared-msr = ~MSR_DE;
+#endif
+ }
+}
+
/*
* Helper function for full MSR writes. No need to call this if only
* EE/CE/ME/DE/RI are changing.
@@ -150,6 +174,7 @@ void kvmppc_set_msr(struct kvm_vcpu *vcpu, u32 new_msr)
kvmppc_mmu_msr_notify(vcpu, old_msr);
kvmppc_vcpu_sync_spe(vcpu);
kvmppc_vcpu_sync_fpu(vcpu);
+ kvmppc_vcpu_sync_debug(vcpu);
}
static void kvmppc_booke_queue_irqprio(struct kvm_vcpu *vcpu,
@@ -736,6 +761,9 @@ static int emulation_exit(struct kvm_run *run, struct
kvm_vcpu *vcpu)
run-exit_reason = KVM_EXIT_DCR;
return RESUME_HOST;
+ case EMULATE_EXIT_USER:
+ return RESUME_HOST;
+
case
Re: [RFC PATCH 6/6] kvm/ppc/mpic: in-kernel MPIC emulation
On 14.02.2013, at 06:49, Scott Wood wrote: Hook the MPIC code up to the KVM interfaces, add locking, etc. TODO: irqfd support Signed-off-by: Scott Wood scottw...@freescale.com Could you please split this patch up on your next respin? Also please make sure you don't have #if 0'ed code in here. Just return to user space with an error when you encounter something you don't know how to handle. 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 2/9] KVM: PPC: Remove unused argument to kvmppc_core_dequeue_external
On 15.02.2013, at 01:00, Paul Mackerras wrote: Currently kvmppc_core_dequeue_external() takes a struct kvm_interrupt * argument and does nothing with it, in any of its implementations. This removes it in order to make things easier for forthcoming in-kernel interrupt controller emulation code. Signed-off-by: Paul Mackerras pau...@samba.org Thanks, applied to kvm-ppc-queue. 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 3/9] KVM: PPC: Book3S: Add kernel emulation for the XICS interrupt controller
On 25.02.2013, at 01:59, Paul Mackerras wrote: On Wed, Feb 20, 2013 at 04:58:54PM -0300, Marcelo Tosatti wrote: This is probably a stupid question, but why the KVM_SET_IRQCHIP/KVM_SET_GSI_ROUTING interface is not appropriate for your purposes? x86 sets up a default GSI-IRQCHIP PIN mapping on creation (during KVM_SET_IRQCHIP), but it can be modified with KVM_SET_GSI_ROUTING. So, I see Scott already answered from the point of view of his MPIC emulation stuff, but I'll answer too from the point of view of my XICS emulation code. My understanding, possibly imperfect, is that in a real system the routing of GSIs to IOAPICs would either be hardwired or set up by the BIOS, described in ACPI tables, and not modified by the operating system. Is that correct? So my belief is that the GSI routing is fundamentally distinct from and handled differently from the routing of interrupts to CPUs, which is fully under the control of the OS. It's a different layer. I guess there's really some confusion on names here :). I'm always confused when I read sources and you apparently get confused when you read about GSIs. GSIs are an ACPI concept. It's not x86 specific, it's also not APIC specific. It's just a global name space for IRQs. Imagine you have 2 MPICs in your system. But you only want to use a single token / numer to access any IRQ on any chip. That's where GSIs come into play. They map different irqchip IRQs onto a flat number space. To speak with x86 names: Virtualization perspective: QEMU - GSI - IOAPIC - LAPIC - CPU Device perspective: Device irq line - IOAPIC - LAPIC - CPU The IOAPIC is the piece of hardware that interrupt lines get attached to. You connect a pin on it to an irq pin of your device. That talks to the LAPIC to actually schedule interrupts on target CPUs. The LAPIC then fetches interrupts and pulls the CPU's interrupt line. Of course, things are slightly more complicated in the x86 world, as everything behind the IOAPIC also carries a payload defining which pin actually got triggered, but you get the idea. So really just consider GSIs as a global flat number space for irqchip pins. Alex In the XICS model we have a set of interrupt sources, each identified by a 24-bit number. Control operations on an interrupt source just identify the source by its number. Thus the interrupt source number is like a GSI, but we don't need to map that to a different space (e.g. IOAPIC identifier and input number) in order to operate on it, we can just operate on it directly. Paul. -- 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 -- 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] KVM: PPC: e500: Expose MMU registers via ONE_REG
On 19.03.2013, at 18:26, Scott Wood wrote:
On 03/19/2013 12:17:11 PM, Mihai Caraman wrote:
diff --git a/arch/powerpc/kvm/e500_mmu.c b/arch/powerpc/kvm/e500_mmu.c
index 66b6e31..b77b855 100644
--- a/arch/powerpc/kvm/e500_mmu.c
+++ b/arch/powerpc/kvm/e500_mmu.c
@@ -596,6 +596,95 @@ int kvmppc_set_sregs_e500_tlb(struct kvm_vcpu *vcpu,
struct kvm_sregs *sregs)
return 0;
}
+int kvmppc_get_one_reg_500_tlb(struct kvm_vcpu *vcpu, u64 id,
+union kvmppc_one_reg *val)
s/500/e500/
+int kvmppc_set_one_reg_500_tlb(struct kvm_vcpu *vcpu, u64 id,
+ union kvmppc_one_reg *val)
+{
+int r = 0;
+long int i;
+
+switch (id) {
+case KVM_REG_PPC_MAS0:
+vcpu-arch.shared-mas0 = set_reg_val(id, *val);
+break;
+case KVM_REG_PPC_MAS1:
+vcpu-arch.shared-mas1 = set_reg_val(id, *val);
+break;
+case KVM_REG_PPC_MAS2:
+vcpu-arch.shared-mas2 = set_reg_val(id, *val);
+break;
+case KVM_REG_PPC_MAS7_3:
+vcpu-arch.shared-mas7_3 = set_reg_val(id, *val);
+break;
+case KVM_REG_PPC_MAS4:
+vcpu-arch.shared-mas4 = set_reg_val(id, *val);
+break;
+case KVM_REG_PPC_MAS6:
+vcpu-arch.shared-mas6 = set_reg_val(id, *val);
+break;
+case KVM_REG_PPC_MMUCFG: {
+u32 mmucfg = set_reg_val(id, *val);
+vcpu-arch.mmucfg = mmucfg ~MMUCFG_LPIDSIZE;
+break;
+}
Do we really want to allow arbitrary MMUCFG changes? It won't magically make
us able to support larger RAs, PIDs, different MAVN, etc.
Only if we update the actual shadow mmu configuration as well.
+case KVM_REG_PPC_TLB0CFG:
+case KVM_REG_PPC_TLB1CFG:
+case KVM_REG_PPC_TLB2CFG:
+case KVM_REG_PPC_TLB3CFG: {
+u32 tlbncfg = set_reg_val(id, *val);
+u32 geometry_mask = TLBnCFG_N_ENTRY | TLBnCFG_ASSOC;
+i = id - KVM_REG_PPC_TLB0CFG;
+
+/* MMU geometry (way/size) can be set only using SW_TLB */
+if ((vcpu-arch.tlbcfg[i] geometry_mask) !=
+(tlbncfg geometry_mask))
+r = -EINVAL;
+
+vcpu-arch.tlbcfg[i] = set_reg_val(id, *val);
+break;
+}
Likewise -- just because QEMU sets a bit here doesn't mean KVM can support it.
I thought the initial plan for setting these config registers was to accept
it if it exactly matches what KVM already has, and give an error otherwise --
thus allowing for the possibliity of accepting certain specific updates in
the future.
Yes, that was the idea :).
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] KVM: PPC: e500: Add separate functions for vcpu's MMU configuration
On 19.03.2013, at 18:16, Mihai Caraman wrote:
Move vcpu's MMU default configuration and geometry update into their own
functions.
Mind to explain why?
Alex
Signed-off-by: Mihai Caraman mihai.cara...@freescale.com
---
arch/powerpc/kvm/e500_mmu.c | 59 +++
1 files changed, 37 insertions(+), 22 deletions(-)
diff --git a/arch/powerpc/kvm/e500_mmu.c b/arch/powerpc/kvm/e500_mmu.c
index 5c44759..66b6e31 100644
--- a/arch/powerpc/kvm/e500_mmu.c
+++ b/arch/powerpc/kvm/e500_mmu.c
@@ -596,6 +596,20 @@ int kvmppc_set_sregs_e500_tlb(struct kvm_vcpu *vcpu,
struct kvm_sregs *sregs)
return 0;
}
+static int vcpu_mmu_geometry_update(struct kvm_vcpu *vcpu,
+ struct kvm_book3e_206_tlb_params *params)
+{
+ vcpu-arch.tlbcfg[0] = ~(TLBnCFG_N_ENTRY | TLBnCFG_ASSOC);
+ if (params-tlb_sizes[0] = 2048)
+ vcpu-arch.tlbcfg[0] |= params-tlb_sizes[0];
+ vcpu-arch.tlbcfg[0] |= params-tlb_ways[0] TLBnCFG_ASSOC_SHIFT;
+
+ vcpu-arch.tlbcfg[1] = ~(TLBnCFG_N_ENTRY | TLBnCFG_ASSOC);
+ vcpu-arch.tlbcfg[1] |= params-tlb_sizes[1];
+ vcpu-arch.tlbcfg[1] |= params-tlb_ways[1] TLBnCFG_ASSOC_SHIFT;
+ return 0;
+}
+
int kvm_vcpu_ioctl_config_tlb(struct kvm_vcpu *vcpu,
struct kvm_config_tlb *cfg)
{
@@ -692,16 +706,8 @@ int kvm_vcpu_ioctl_config_tlb(struct kvm_vcpu *vcpu,
vcpu_e500-gtlb_offset[0] = 0;
vcpu_e500-gtlb_offset[1] = params.tlb_sizes[0];
- vcpu-arch.mmucfg = mfspr(SPRN_MMUCFG) ~MMUCFG_LPIDSIZE;
-
- vcpu-arch.tlbcfg[0] = ~(TLBnCFG_N_ENTRY | TLBnCFG_ASSOC);
- if (params.tlb_sizes[0] = 2048)
- vcpu-arch.tlbcfg[0] |= params.tlb_sizes[0];
- vcpu-arch.tlbcfg[0] |= params.tlb_ways[0] TLBnCFG_ASSOC_SHIFT;
-
- vcpu-arch.tlbcfg[1] = ~(TLBnCFG_N_ENTRY | TLBnCFG_ASSOC);
- vcpu-arch.tlbcfg[1] |= params.tlb_sizes[1];
- vcpu-arch.tlbcfg[1] |= params.tlb_ways[1] TLBnCFG_ASSOC_SHIFT;
+ /* Update vcpu's MMU geometry based on SW_TLB input */
+ vcpu_mmu_geometry_update(vcpu, params);
vcpu_e500-shared_tlb_pages = pages;
vcpu_e500-num_shared_tlb_pages = num_pages;
@@ -737,6 +743,26 @@ int kvm_vcpu_ioctl_dirty_tlb(struct kvm_vcpu *vcpu,
return 0;
}
+/* vcpu's MMU default configuration */
+static int vcpu_mmu_init(struct kvm_vcpu *vcpu,
+struct kvmppc_e500_tlb_params *params)
+{
+ /* Initialize RASIZE, PIDSIZE, NTLBS and MAVN fields with host values*/
+ vcpu-arch.mmucfg = mfspr(SPRN_MMUCFG) ~MMUCFG_LPIDSIZE;
+
+ /* Initialize IPROT field with host value*/
+ vcpu-arch.tlbcfg[0] = mfspr(SPRN_TLB0CFG)
+ ~(TLBnCFG_N_ENTRY | TLBnCFG_ASSOC);
+ vcpu-arch.tlbcfg[0] |= params[0].entries;
+ vcpu-arch.tlbcfg[0] |= params[0].ways TLBnCFG_ASSOC_SHIFT;
+
+ vcpu-arch.tlbcfg[1] = mfspr(SPRN_TLB1CFG)
+ ~(TLBnCFG_N_ENTRY | TLBnCFG_ASSOC);
+ vcpu-arch.tlbcfg[1] |= params[1].entries;
+ vcpu-arch.tlbcfg[1] |= params[1].ways TLBnCFG_ASSOC_SHIFT;
+ return 0;
+}
+
int kvmppc_e500_tlb_init(struct kvmppc_vcpu_e500 *vcpu_e500)
{
struct kvm_vcpu *vcpu = vcpu_e500-vcpu;
@@ -781,18 +807,7 @@ int kvmppc_e500_tlb_init(struct kvmppc_vcpu_e500
*vcpu_e500)
if (!vcpu_e500-g2h_tlb1_map)
goto err;
- /* Init TLB configuration register */
- vcpu-arch.tlbcfg[0] = mfspr(SPRN_TLB0CFG)
- ~(TLBnCFG_N_ENTRY | TLBnCFG_ASSOC);
- vcpu-arch.tlbcfg[0] |= vcpu_e500-gtlb_params[0].entries;
- vcpu-arch.tlbcfg[0] |=
- vcpu_e500-gtlb_params[0].ways TLBnCFG_ASSOC_SHIFT;
-
- vcpu-arch.tlbcfg[1] = mfspr(SPRN_TLB1CFG)
- ~(TLBnCFG_N_ENTRY | TLBnCFG_ASSOC);
- vcpu-arch.tlbcfg[1] |= vcpu_e500-gtlb_params[1].entries;
- vcpu-arch.tlbcfg[1] |=
- vcpu_e500-gtlb_params[1].ways TLBnCFG_ASSOC_SHIFT;
+ vcpu_mmu_init(vcpu, vcpu_e500-gtlb_params);
kvmppc_recalc_tlb1map_range(vcpu_e500);
return 0;
--
1.7.4.1
--
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
--
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] KVM: PPC: e500: Expose MMU registers via ONE_REG
-Original Message-
From: Alexander Graf [mailto:ag...@suse.de]
Sent: Thursday, March 21, 2013 12:07 PM
To: Wood Scott-B07421
Cc: Caraman Mihai Claudiu-B02008; kvm-ppc@vger.kernel.org; linuxppc-
d...@lists.ozlabs.org; k...@vger.kernel.org
Subject: Re: [PATCH] KVM: PPC: e500: Expose MMU registers via ONE_REG
On 19.03.2013, at 18:26, Scott Wood wrote:
On 03/19/2013 12:17:11 PM, Mihai Caraman wrote:
diff --git a/arch/powerpc/kvm/e500_mmu.c b/arch/powerpc/kvm/e500_mmu.c
index 66b6e31..b77b855 100644
--- a/arch/powerpc/kvm/e500_mmu.c
+++ b/arch/powerpc/kvm/e500_mmu.c
@@ -596,6 +596,95 @@ int kvmppc_set_sregs_e500_tlb(struct kvm_vcpu
*vcpu, struct kvm_sregs *sregs)
return 0;
}
+int kvmppc_get_one_reg_500_tlb(struct kvm_vcpu *vcpu, u64 id,
+ union kvmppc_one_reg *val)
s/500/e500/
+int kvmppc_set_one_reg_500_tlb(struct kvm_vcpu *vcpu, u64 id,
+ union kvmppc_one_reg *val)
+{
+ int r = 0;
+ long int i;
+
+ switch (id) {
+ case KVM_REG_PPC_MAS0:
+ vcpu-arch.shared-mas0 = set_reg_val(id, *val);
+ break;
+ case KVM_REG_PPC_MAS1:
+ vcpu-arch.shared-mas1 = set_reg_val(id, *val);
+ break;
+ case KVM_REG_PPC_MAS2:
+ vcpu-arch.shared-mas2 = set_reg_val(id, *val);
+ break;
+ case KVM_REG_PPC_MAS7_3:
+ vcpu-arch.shared-mas7_3 = set_reg_val(id, *val);
+ break;
+ case KVM_REG_PPC_MAS4:
+ vcpu-arch.shared-mas4 = set_reg_val(id, *val);
+ break;
+ case KVM_REG_PPC_MAS6:
+ vcpu-arch.shared-mas6 = set_reg_val(id, *val);
+ break;
+ case KVM_REG_PPC_MMUCFG: {
+ u32 mmucfg = set_reg_val(id, *val);
+ vcpu-arch.mmucfg = mmucfg ~MMUCFG_LPIDSIZE;
+ break;
+ }
Do we really want to allow arbitrary MMUCFG changes? It won't
magically make us able to support larger RAs, PIDs, different MAVN, etc.
Not magically, some changes e.g TLBnCFG_IND or TLBnPS require just a kvm
check other changes e.g. TLBnCFG_MAVN require additional support and we
might not implement all of them. Until then this code should do the job:
/* MMU registers can be set only to the configuration supported by KVM
*/
case KVM_REG_PPC_MMUCFG: {
if (set_reg_val(id, *val) != vcpu-arch.mmucfg)
r = -EINVAL;
break;
}
Only if we update the actual shadow mmu configuration as well.
These registers (MMUCFG, EPTCFG, TLBnCFG, TLBnPS) are read-only (and shared
between e6500 threads), we can only emulate them.
-Mike
--
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] KVM: PPC: e500: Expose MMU registers via ONE_REG
On 21.03.2013, at 12:02, Caraman Mihai Claudiu-B02008 wrote:
-Original Message-
From: Alexander Graf [mailto:ag...@suse.de]
Sent: Thursday, March 21, 2013 12:07 PM
To: Wood Scott-B07421
Cc: Caraman Mihai Claudiu-B02008; kvm-ppc@vger.kernel.org; linuxppc-
d...@lists.ozlabs.org; k...@vger.kernel.org
Subject: Re: [PATCH] KVM: PPC: e500: Expose MMU registers via ONE_REG
On 19.03.2013, at 18:26, Scott Wood wrote:
On 03/19/2013 12:17:11 PM, Mihai Caraman wrote:
diff --git a/arch/powerpc/kvm/e500_mmu.c b/arch/powerpc/kvm/e500_mmu.c
index 66b6e31..b77b855 100644
--- a/arch/powerpc/kvm/e500_mmu.c
+++ b/arch/powerpc/kvm/e500_mmu.c
@@ -596,6 +596,95 @@ int kvmppc_set_sregs_e500_tlb(struct kvm_vcpu
*vcpu, struct kvm_sregs *sregs)
return 0;
}
+int kvmppc_get_one_reg_500_tlb(struct kvm_vcpu *vcpu, u64 id,
+ union kvmppc_one_reg *val)
s/500/e500/
+int kvmppc_set_one_reg_500_tlb(struct kvm_vcpu *vcpu, u64 id,
+ union kvmppc_one_reg *val)
+{
+ int r = 0;
+ long int i;
+
+ switch (id) {
+ case KVM_REG_PPC_MAS0:
+ vcpu-arch.shared-mas0 = set_reg_val(id, *val);
+ break;
+ case KVM_REG_PPC_MAS1:
+ vcpu-arch.shared-mas1 = set_reg_val(id, *val);
+ break;
+ case KVM_REG_PPC_MAS2:
+ vcpu-arch.shared-mas2 = set_reg_val(id, *val);
+ break;
+ case KVM_REG_PPC_MAS7_3:
+ vcpu-arch.shared-mas7_3 = set_reg_val(id, *val);
+ break;
+ case KVM_REG_PPC_MAS4:
+ vcpu-arch.shared-mas4 = set_reg_val(id, *val);
+ break;
+ case KVM_REG_PPC_MAS6:
+ vcpu-arch.shared-mas6 = set_reg_val(id, *val);
+ break;
+ case KVM_REG_PPC_MMUCFG: {
+ u32 mmucfg = set_reg_val(id, *val);
+ vcpu-arch.mmucfg = mmucfg ~MMUCFG_LPIDSIZE;
+ break;
+ }
Do we really want to allow arbitrary MMUCFG changes? It won't
magically make us able to support larger RAs, PIDs, different MAVN, etc.
Not magically, some changes e.g TLBnCFG_IND or TLBnPS require just a kvm
check other changes e.g. TLBnCFG_MAVN require additional support and we
might not implement all of them. Until then this code should do the job:
/* MMU registers can be set only to the configuration supported by KVM
*/
case KVM_REG_PPC_MMUCFG: {
if (set_reg_val(id, *val) != vcpu-arch.mmucfg)
r = -EINVAL;
break;
}
Yes :).
Only if we update the actual shadow mmu configuration as well.
These registers (MMUCFG, EPTCFG, TLBnCFG, TLBnPS) are read-only (and shared
between e6500 threads), we can only emulate them.
We need to change the behavior of the shadow mmu as well. It's not about the
registers, but the actually exposed TLBs. If you configure 4 TLBs, and you
announce to the guest that you can do 4 TLBs, you better emulate 4 TLBs :).
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] KVM: PPC: e500: Add separate functions for vcpu's MMU configuration
-Original Message-
From: kvm-ppc-ow...@vger.kernel.org [mailto:kvm-ppc-
ow...@vger.kernel.org] On Behalf Of Alexander Graf
Sent: Thursday, March 21, 2013 12:07 PM
To: Caraman Mihai Claudiu-B02008
Cc: kvm-ppc@vger.kernel.org; k...@vger.kernel.org; linuxppc-
d...@lists.ozlabs.org
Subject: Re: [PATCH] KVM: PPC: e500: Add separate functions for vcpu's
MMU configuration
On 19.03.2013, at 18:16, Mihai Caraman wrote:
Move vcpu's MMU default configuration and geometry update into their
own
functions.
Mind to explain why?
You requested a separate function for clearing TLBnCFG_IND bit (E.PT removal)
to self-document the code. The existing logic (that TLBnCFG_IND relies on)
was buried in a chunk of code and I thought this will add more clarity.
If you don't agree I would document the code at least.
-Mike
Alex
Signed-off-by: Mihai Caraman mihai.cara...@freescale.com
---
arch/powerpc/kvm/e500_mmu.c | 59 +++-
---
1 files changed, 37 insertions(+), 22 deletions(-)
diff --git a/arch/powerpc/kvm/e500_mmu.c b/arch/powerpc/kvm/e500_mmu.c
index 5c44759..66b6e31 100644
--- a/arch/powerpc/kvm/e500_mmu.c
+++ b/arch/powerpc/kvm/e500_mmu.c
@@ -596,6 +596,20 @@ int kvmppc_set_sregs_e500_tlb(struct kvm_vcpu
*vcpu, struct kvm_sregs *sregs)
return 0;
}
+static int vcpu_mmu_geometry_update(struct kvm_vcpu *vcpu,
+ struct kvm_book3e_206_tlb_params *params)
+{
+ vcpu-arch.tlbcfg[0] = ~(TLBnCFG_N_ENTRY | TLBnCFG_ASSOC);
+ if (params-tlb_sizes[0] = 2048)
+ vcpu-arch.tlbcfg[0] |= params-tlb_sizes[0];
+ vcpu-arch.tlbcfg[0] |= params-tlb_ways[0] TLBnCFG_ASSOC_SHIFT;
+
+ vcpu-arch.tlbcfg[1] = ~(TLBnCFG_N_ENTRY | TLBnCFG_ASSOC);
+ vcpu-arch.tlbcfg[1] |= params-tlb_sizes[1];
+ vcpu-arch.tlbcfg[1] |= params-tlb_ways[1] TLBnCFG_ASSOC_SHIFT;
+ return 0;
+}
+
int kvm_vcpu_ioctl_config_tlb(struct kvm_vcpu *vcpu,
struct kvm_config_tlb *cfg)
{
@@ -692,16 +706,8 @@ int kvm_vcpu_ioctl_config_tlb(struct kvm_vcpu
*vcpu,
vcpu_e500-gtlb_offset[0] = 0;
vcpu_e500-gtlb_offset[1] = params.tlb_sizes[0];
- vcpu-arch.mmucfg = mfspr(SPRN_MMUCFG) ~MMUCFG_LPIDSIZE;
-
- vcpu-arch.tlbcfg[0] = ~(TLBnCFG_N_ENTRY | TLBnCFG_ASSOC);
- if (params.tlb_sizes[0] = 2048)
- vcpu-arch.tlbcfg[0] |= params.tlb_sizes[0];
- vcpu-arch.tlbcfg[0] |= params.tlb_ways[0] TLBnCFG_ASSOC_SHIFT;
-
- vcpu-arch.tlbcfg[1] = ~(TLBnCFG_N_ENTRY | TLBnCFG_ASSOC);
- vcpu-arch.tlbcfg[1] |= params.tlb_sizes[1];
- vcpu-arch.tlbcfg[1] |= params.tlb_ways[1] TLBnCFG_ASSOC_SHIFT;
+ /* Update vcpu's MMU geometry based on SW_TLB input */
+ vcpu_mmu_geometry_update(vcpu, params);
vcpu_e500-shared_tlb_pages = pages;
vcpu_e500-num_shared_tlb_pages = num_pages;
@@ -737,6 +743,26 @@ int kvm_vcpu_ioctl_dirty_tlb(struct kvm_vcpu
*vcpu,
return 0;
}
+/* vcpu's MMU default configuration */
+static int vcpu_mmu_init(struct kvm_vcpu *vcpu,
+ struct kvmppc_e500_tlb_params *params)
+{
+ /* Initialize RASIZE, PIDSIZE, NTLBS and MAVN fields with host
values*/
+ vcpu-arch.mmucfg = mfspr(SPRN_MMUCFG) ~MMUCFG_LPIDSIZE;
+
+ /* Initialize IPROT field with host value*/
+ vcpu-arch.tlbcfg[0] = mfspr(SPRN_TLB0CFG)
+~(TLBnCFG_N_ENTRY | TLBnCFG_ASSOC);
+ vcpu-arch.tlbcfg[0] |= params[0].entries;
+ vcpu-arch.tlbcfg[0] |= params[0].ways TLBnCFG_ASSOC_SHIFT;
+
+ vcpu-arch.tlbcfg[1] = mfspr(SPRN_TLB1CFG)
+~(TLBnCFG_N_ENTRY | TLBnCFG_ASSOC);
+ vcpu-arch.tlbcfg[1] |= params[1].entries;
+ vcpu-arch.tlbcfg[1] |= params[1].ways TLBnCFG_ASSOC_SHIFT;
+ return 0;
+}
+
int kvmppc_e500_tlb_init(struct kvmppc_vcpu_e500 *vcpu_e500)
{
struct kvm_vcpu *vcpu = vcpu_e500-vcpu;
@@ -781,18 +807,7 @@ int kvmppc_e500_tlb_init(struct kvmppc_vcpu_e500
*vcpu_e500)
if (!vcpu_e500-g2h_tlb1_map)
goto err;
- /* Init TLB configuration register */
- vcpu-arch.tlbcfg[0] = mfspr(SPRN_TLB0CFG)
-~(TLBnCFG_N_ENTRY | TLBnCFG_ASSOC);
- vcpu-arch.tlbcfg[0] |= vcpu_e500-gtlb_params[0].entries;
- vcpu-arch.tlbcfg[0] |=
- vcpu_e500-gtlb_params[0].ways TLBnCFG_ASSOC_SHIFT;
-
- vcpu-arch.tlbcfg[1] = mfspr(SPRN_TLB1CFG)
-~(TLBnCFG_N_ENTRY | TLBnCFG_ASSOC);
- vcpu-arch.tlbcfg[1] |= vcpu_e500-gtlb_params[1].entries;
- vcpu-arch.tlbcfg[1] |=
- vcpu_e500-gtlb_params[1].ways TLBnCFG_ASSOC_SHIFT;
+ vcpu_mmu_init(vcpu, vcpu_e500-gtlb_params);
kvmppc_recalc_tlb1map_range(vcpu_e500);
return 0;
--
1.7.4.1
--
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
RE: [PATCH] KVM: PPC: e500: Expose MMU registers via ONE_REG
-Original Message-
From: Alexander Graf [mailto:ag...@suse.de]
Sent: Thursday, March 21, 2013 1:07 PM
To: Caraman Mihai Claudiu-B02008
Cc: Wood Scott-B07421; kvm-ppc@vger.kernel.org; linuxppc-
d...@lists.ozlabs.org; k...@vger.kernel.org
Subject: Re: [PATCH] KVM: PPC: e500: Expose MMU registers via ONE_REG
On 21.03.2013, at 12:02, Caraman Mihai Claudiu-B02008 wrote:
-Original Message-
From: Alexander Graf [mailto:ag...@suse.de]
Sent: Thursday, March 21, 2013 12:07 PM
To: Wood Scott-B07421
Cc: Caraman Mihai Claudiu-B02008; kvm-ppc@vger.kernel.org; linuxppc-
d...@lists.ozlabs.org; k...@vger.kernel.org
Subject: Re: [PATCH] KVM: PPC: e500: Expose MMU registers via ONE_REG
On 19.03.2013, at 18:26, Scott Wood wrote:
On 03/19/2013 12:17:11 PM, Mihai Caraman wrote:
diff --git a/arch/powerpc/kvm/e500_mmu.c
b/arch/powerpc/kvm/e500_mmu.c
index 66b6e31..b77b855 100644
--- a/arch/powerpc/kvm/e500_mmu.c
+++ b/arch/powerpc/kvm/e500_mmu.c
@@ -596,6 +596,95 @@ int kvmppc_set_sregs_e500_tlb(struct kvm_vcpu
*vcpu, struct kvm_sregs *sregs)
return 0;
}
+int kvmppc_get_one_reg_500_tlb(struct kvm_vcpu *vcpu, u64 id,
+union kvmppc_one_reg *val)
s/500/e500/
+int kvmppc_set_one_reg_500_tlb(struct kvm_vcpu *vcpu, u64 id,
+ union kvmppc_one_reg *val)
+{
+int r = 0;
+long int i;
+
+switch (id) {
+case KVM_REG_PPC_MAS0:
+vcpu-arch.shared-mas0 = set_reg_val(id, *val);
+break;
+case KVM_REG_PPC_MAS1:
+vcpu-arch.shared-mas1 = set_reg_val(id, *val);
+break;
+case KVM_REG_PPC_MAS2:
+vcpu-arch.shared-mas2 = set_reg_val(id, *val);
+break;
+case KVM_REG_PPC_MAS7_3:
+vcpu-arch.shared-mas7_3 = set_reg_val(id, *val);
+break;
+case KVM_REG_PPC_MAS4:
+vcpu-arch.shared-mas4 = set_reg_val(id, *val);
+break;
+case KVM_REG_PPC_MAS6:
+vcpu-arch.shared-mas6 = set_reg_val(id, *val);
+break;
+case KVM_REG_PPC_MMUCFG: {
+u32 mmucfg = set_reg_val(id, *val);
+vcpu-arch.mmucfg = mmucfg ~MMUCFG_LPIDSIZE;
+break;
+}
Do we really want to allow arbitrary MMUCFG changes? It won't
magically make us able to support larger RAs, PIDs, different MAVN,
etc.
Not magically, some changes e.g TLBnCFG_IND or TLBnPS require just a
kvm
check other changes e.g. TLBnCFG_MAVN require additional support and we
might not implement all of them. Until then this code should do the
job:
/* MMU registers can be set only to the configuration supported by
KVM */
case KVM_REG_PPC_MMUCFG: {
if (set_reg_val(id, *val) != vcpu-arch.mmucfg)
r = -EINVAL;
break;
}
Yes :).
Only if we update the actual shadow mmu configuration as well.
These registers (MMUCFG, EPTCFG, TLBnCFG, TLBnPS) are read-only (and
shared
between e6500 threads), we can only emulate them.
We need to change the behavior of the shadow mmu as well. It's not about
the registers, but the actually exposed TLBs. If you configure 4 TLBs,
and you announce to the guest that you can do 4 TLBs, you better emulate
4 TLBs :).
Right, like the rest of configs I was talking above:)
-Mike
--
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] KVM: PPC: e500: Add separate functions for vcpu's MMU configuration
On 21.03.2013, at 12:19, Caraman Mihai Claudiu-B02008 wrote: -Original Message- From: kvm-ppc-ow...@vger.kernel.org [mailto:kvm-ppc- ow...@vger.kernel.org] On Behalf Of Alexander Graf Sent: Thursday, March 21, 2013 12:07 PM To: Caraman Mihai Claudiu-B02008 Cc: kvm-ppc@vger.kernel.org; k...@vger.kernel.org; linuxppc- d...@lists.ozlabs.org Subject: Re: [PATCH] KVM: PPC: e500: Add separate functions for vcpu's MMU configuration On 19.03.2013, at 18:16, Mihai Caraman wrote: Move vcpu's MMU default configuration and geometry update into their own functions. Mind to explain why? You requested a separate function for clearing TLBnCFG_IND bit (E.PT removal) to self-document the code. The existing logic (that TLBnCFG_IND relies on) was buried in a chunk of code and I thought this will add more clarity. If you don't agree I would document the code at least. I guess I'll have to see the full picture then. Please just include this patch in the series when you change the IND bit and make the patch description a bit more obvious: Just indicate that you need this a cleanup to make the IND patch more readable. 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: [RFC PATCH 6/6] kvm/ppc/mpic: in-kernel MPIC emulation
On 03/21/2013 03:28:35 AM, Alexander Graf wrote: On 14.02.2013, at 06:49, Scott Wood wrote: Hook the MPIC code up to the KVM interfaces, add locking, etc. TODO: irqfd support Signed-off-by: Scott Wood scottw...@freescale.com Could you please split this patch up on your next respin? Any particular split you're looking for? The only reason it's split as much as it is already is to give some chance of merging updates from QEMU being less painful. As far as the kernel is concerned, this is new code, which is not functional (and thus not built) before this patch. There aren't meaningful intermediate states. Also please make sure you don't have #if 0'ed code in here. Well, yeah. Note the RFC. :-) -Scott -- 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: [RFC PATCH 6/6] kvm/ppc/mpic: in-kernel MPIC emulation
On 21.03.2013, at 15:43, Scott Wood wrote: On 03/21/2013 03:28:35 AM, Alexander Graf wrote: On 14.02.2013, at 06:49, Scott Wood wrote: Hook the MPIC code up to the KVM interfaces, add locking, etc. TODO: irqfd support Signed-off-by: Scott Wood scottw...@freescale.com Could you please split this patch up on your next respin? Any particular split you're looking for? Anything that makes reviewing it easier :). I can't concentrate for 100k straight. The only reason it's split as much as it is already is to give some chance of merging updates from QEMU being less painful. As far as the kernel is concerned, this is new code, which is not functional (and thus not built) before this patch. There aren't meaningful intermediate states. Also please make sure you don't have #if 0'ed code in here. Well, yeah. Note the RFC. :-) Just wanted to make sure you don't forget them when you send out a non-RFC :). Not that I'd assume you'd do that ;) Alex -- To unsubscribe from this list: send the line unsubscribe kvm-ppc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
