On 08.07.2009, at 07:24, Benjamin Herrenschmidt wrote:
On Tue, 2009-07-07 at 16:17 +0200, Alexander Graf wrote:
Getting from host state to the guest is only half the story. We
also need
to return to our host context and handle whatever happened to get
us out of
the guest.
On PowerPC every guest exit is an interrupt. So all we need to do
is trap
the host's interrupt handlers and get into our #VMEXIT code to
handle it.
PowerPCs also have a register that can add an offset to the
interrupt handlers'
adresses which is what the booke KVM code uses. Unfortunately that
is a
hypervisor ressource and we also want to be able to run KVM when
we're running
in an LPAR. So we have to hook into the Linux interrupt handlers.
Right, besides it doesn't always work :-)
Signed-off-by: Alexander Graf <ag...@suse.de>
---
arch/powerpc/kvm/970_rmhandlers.S | 128 +++++++++++++++++++++++++++
++++++++++
1 files changed, 128 insertions(+), 0 deletions(-)
create mode 100644 arch/powerpc/kvm/970_rmhandlers.S
diff --git a/arch/powerpc/kvm/970_rmhandlers.S b/arch/powerpc/kvm/
970_rmhandlers.S
new file mode 100644
index 0000000..91dacc4
--- /dev/null
+++ b/arch/powerpc/kvm/970_rmhandlers.S
@@ -0,0 +1,128 @@
+/*
+ * This program is free software; you can redistribute it and/or
modify
+ * it under the terms of the GNU General Public License, version
2, as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, 51 Franklin Street, Fifth Floor, Boston, MA
02110-1301, USA.
+ *
+ * Copyright SUSE Linux Products GmbH 2009
+ *
+ * Authors: Alexander Graf <ag...@suse.de>
+ */
+
+#include <asm/kvm_970_asm.h>
+
+/
*****************************************************************************
+
* *
+ * Real Mode handlers that need to be in low physical
memory *
+
* *
+
****************************************************************************/
+
+
+.macro INTERRUPT_TRAMPOLINE intno
+
+.global kvmppc_trampoline_\intno
+kvmppc_trampoline_\intno:
+ /* We're replacing this instruction in the real handler */
+ mtspr SPRN_SPRG1, r13 /* Save r13 */
+ /*
+ * First thing to do is to find out if we're coming
+ * from a KVM guest or a Linux process.
+ *
+ * To distinguish, we only need to check SPRG3 (PACA),
+ * because our entry code sets SPRG3 = PACA | 1, while
+ * Linux has the PACA on at least word boundary.
+ */
+ mfcr r13
+ mtspr SPRN_SPRG2, r13 /* Save CR */
+ mfspr r13, SPRN_SPRG3 /* r13 = PACA | 1 */
+ clrldi. r13, r13, 63 /* CR = ((r13 & 1) == 0) */
+ bne ..kvmppc_handler_hasmagic_\intno
+ /* No KVM guest? Then jump back to the Linux handler! */
+ mfspr r13, SPRN_SPRG2
+ mtcr r13
+ mfspr r13, SPRN_SPRG1 /* r13 = original r13 */
+ b kvmppc_resume_\intno /* Get back original handler */
+
+ /* Now we know we're handling a KVM guest */
+..kvmppc_handler_hasmagic_\intno:
+ /* Unset SPRG3 */
+ mfspr r13, SPRN_SPRG3 /* r13 = PACA */
+ clrrdi r13, r13, 1 /* r13 &= ~1 */
+ mtspr SPRN_SPRG3, r13 /* SPRG3 = PACA & ~1 */
What about instead, we make the generic interrupt entry test the PACA
low bit and branch off to a KVM supplied function table ? That would
lower the overhead and avoid having to do any kind of patching no ?
I'm
happy to have that logic permanently in there, maybe controlled by a
CONFIG option in case somebody wants to do kernel that never do KVM,
if
we can make it such that it doesn't bloat things.
Hum, something like a generic interrupt hooking mechanism? Sounds
cool :-). But not all interrupt handlers use generic code, so we'd
have to duplicate some bits quite some times.
Alex
In fact we could even have it there, NOP it out when KVM isn't loaded
and put the instructions back when KVM is.
Cheers,
Ben.
--
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
