Re: [PATCH 00/31] KVM/MIPS: Implement hardware virtualization via the MIPS-VZ extensions.
FYI, Since you intend to resubmit anyway I just dropped the entire series from patchwork. Ralf -- 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 00/31] KVM/MIPS: Implement hardware virtualization via the MIPS-VZ extensions.
On Sun, Jun 09, 2013 at 04:23:51PM -0700, David Daney wrote: Come to think of it, Emulating SGI hardware might be an interesting case. There may be old IRIX systems and applications that could be running low on real hardware. Some of those systems take up a whole room and draw a lot of power. They might run faster and at much lower power consumption on a modern 48-Way SMP SoC based system. Many SGI MIPS system have RTCs powered by builtin batteries with a nominal livetime of ten years and for which no more replacements are available. This is beginning to limit usable SGI MIPS systems to those who know how to solve these issues with a Dremel and a soldering iron. That said, SGI platforms are all more or less weird custom architectures so the platform emulation - let alone the firmware blobs - will be a chunk of work. Ralf -- 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 00/31] KVM/MIPS: Implement hardware virtualization via the MIPS-VZ extensions.
On Fri, Jun 07, 2013 at 04:03:04PM -0700, David Daney wrote: Subject: [PATCH 00/31] KVM/MIPS: Implement hardware virtualization via the MIPS-VZ extensions. From: David Daney david.da...@cavium.com These patches take a somewhat different approach to MIPS virtualization via the MIPS-VZ extensions than the patches previously sent by Sanjay Lal. Several facts about the code: o Existing exception handlers are modified to hook in to KVM instead of intercepting all exceptions via the EBase register, and then chaining to real exception handlers. o Able to boot 64-bit SMP guests that use the FPU (I have booted 4-way SMP 64-bit MIPS/Linux). o Additional overhead on every exception even when *no* vCPU is running. o Lower interrupt overhead, than the EBase interception method, when vCPU *is* running. o This code is somewhat smaller than the existing trap/emulate implementation (about 2100 lines vs. about 5300 lines) o Currently probably only usable on the OCTEON III CPU model, as some MIPS-VZ implementation-defined behaviors were assumed to have the OCTEON III behavior. Note: I think Ralf already has the 17/31 (MIPS: Quit exposing Kconfig symbols in uapi headers.) queued, but I also include it here. Yes; as the references to CONFIG_* symbols in UAPI were a bug, I've already merged this patch for 3.10 as 8f657933a3c2086d4731350c98f91a990783c0d3 [MIPS: Quit exposing Kconfig symbols in uapi headers.] Ralf -- 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 00/31] KVM/MIPS: Implement hardware virtualization via the MIPS-VZ extensions.
On Sun, Jun 09, 2013 at 04:23:51PM -0700, David Daney wrote: On 06/09/2013 12:31 AM, Gleb Natapov wrote: On Fri, Jun 07, 2013 at 04:15:00PM -0700, David Daney wrote: I should also add that I will shortly send patches for the kvm tool required to drive this VM as well as a small set of patches that create a para-virtualized MIPS/Linux guest kernel. The idea is that because there is no standard SMP linux system, we create a standard para-virtualized system that uses a handful of hypercalls, but mostly just uses virtio devices. It has no emulated real hardware (no 8250 UART, no emulated legacy anything...) Virtualization is useful for running legacy code. Why dismiss support for non pv guests so easily? Just because we create standard PV system devices, doesn't preclude emulating real hardware. In fact Sanjay Lal's work includes QEMU support for doing just this for a MIPS malta board. I just wanted a very simple system I could implement with the kvm tool in a couple of days, so that is what I initially did. That makes sense. From your wording I misunderstood that there is something in proposed patches that requires PV to run a guest. -- 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 00/31] KVM/MIPS: Implement hardware virtualization via the MIPS-VZ extensions.
On Mon, Jun 10, 2013 at 12:40:42AM +0100, Maciej W. Rozycki wrote: How different MIPS SMP systems are? o Old SGI heavy metal (several different system architectures). o Cavium OCTEON SMP SoCs. o Broadcom (several flavors) SoCs o Loongson o Old DEC hardware (DECsystem 58x0, R3000-based). o Malta-based MIPS Technologies CMP solutions (1004K, 1074K, interAptiv). And more. It's fairly accurate that MIPS SMP system tend to have little of their system architecture in common beyond the underlying processor architecture and everything else should be treated as a lucky coincidence. Ralf -- 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 00/31] KVM/MIPS: Implement hardware virtualization via the MIPS-VZ extensions.
On Jun 9, 2013, at 4:23 PM, David Daney wrote: On 06/09/2013 12:31 AM, Gleb Natapov wrote: On Fri, Jun 07, 2013 at 04:15:00PM -0700, David Daney wrote: I should also add that I will shortly send patches for the kvm tool required to drive this VM as well as a small set of patches that create a para-virtualized MIPS/Linux guest kernel. The idea is that because there is no standard SMP linux system, we create a standard para-virtualized system that uses a handful of hypercalls, but mostly just uses virtio devices. It has no emulated real hardware (no 8250 UART, no emulated legacy anything...) Virtualization is useful for running legacy code. Why dismiss support for non pv guests so easily? Just because we create standard PV system devices, doesn't preclude emulating real hardware. In fact Sanjay Lal's work includes QEMU support for doing just this for a MIPS malta board. I just wanted a very simple system I could implement with the kvm tool in a couple of days, so that is what I initially did. The problem is that almost nobody has real malta boards, they are really only of interest because QEMU implements a virtual malta board. Personally, I see the most interesting us cases of MIPS KVM being a deployment platform for new services, so legacy support is not so important to me. That doesn't mean that other people wouldn't want some sort of legacy support. The problem with 'legacy' on MIPS is that there are hundreds of legacies to choose from (Old SGI and DEC hardware, various network hardware from many different vendors, etc.). Which would you choose? How different MIPS SMP systems are? o Old SGI heavy metal (several different system architectures). o Cavium OCTEON SMP SoCs. o Broadcom (several flavors) SoCs o Loongson Come to think of it, Emulating SGI hardware might be an interesting case. There may be old IRIX systems and applications that could be running low on real hardware. Some of those systems take up a whole room and draw a lot of power. They might run faster and at much lower power consumption on a modern 48-Way SMP SoC based system. What about running non pv UP systems? See above. I think this is what Sanjay Lal is doing. The KVM implementation from MIPS (currently in mainline) supports UP systems in trap and emulate mode. The patch set I posted earlier adding VZ support also supports SMP. We leverage the Malta board emulation in QEMU to offer full non-PV virtualization: UP system: Malta board with a MIPS 24K processor SMP system: Malta board with a 1074K CMP processor cluster with a GIC. When it comes to PV/non-PV support, I see the two implementations as complementary. If people want full legacy system emulation without any kernel modifications, then they can run the full QEMU/KVM stack, while people interested in pure PV solutions can run the lkvm version. Regards Sanjay -- 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 00/31] KVM/MIPS: Implement hardware virtualization via the MIPS-VZ extensions.
On Jun 7, 2013, at 4:03 PM, David Daney wrote: From: David Daney david.da...@cavium.com These patches take a somewhat different approach to MIPS virtualization via the MIPS-VZ extensions than the patches previously sent by Sanjay Lal. Several facts about the code: o Currently probably only usable on the OCTEON III CPU model, as some MIPS-VZ implementation-defined behaviors were assumed to have the OCTEON III behavior. I've only briefly gone over the patches, but I was wondering if the Cavium implementation has support for GuestIDs, which are optional in the VZ-ASE? Regards Sanjay -- 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 00/31] KVM/MIPS: Implement hardware virtualization via the MIPS-VZ extensions.
On 06/10/2013 09:43 AM, Sanjay Lal wrote: On Jun 7, 2013, at 4:03 PM, David Daney wrote: From: David Daney david.da...@cavium.com These patches take a somewhat different approach to MIPS virtualization via the MIPS-VZ extensions than the patches previously sent by Sanjay Lal. Several facts about the code: o Currently probably only usable on the OCTEON III CPU model, as some MIPS-VZ implementation-defined behaviors were assumed to have the OCTEON III behavior. I've only briefly gone over the patches, but I was wondering if the Cavium implementation has support for GuestIDs, which are optional in the VZ-ASE? No, OCTEON III does not support this optional behavior. For the most part this only impacts TLB management. I think in the context of KVM, you cannot leave foreign Guest's TLB entries present in the Guest TLB anyhow, so the feature is of little use. Since MIPS TLBs are managed by software, it is valid for a guest to populate the TLB in any way it desires. To have the hypervisor (KVM) come and randomly invalidate the TLB, via the GuestID mechanism, would both be detectable by the guest, and potentially make the guest operate incorrectly. David Daney Regards Sanjay -- 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 00/31] KVM/MIPS: Implement hardware virtualization via the MIPS-VZ extensions.
On Fri, Jun 07, 2013 at 04:15:00PM -0700, David Daney wrote: I should also add that I will shortly send patches for the kvm tool required to drive this VM as well as a small set of patches that create a para-virtualized MIPS/Linux guest kernel. The idea is that because there is no standard SMP linux system, we create a standard para-virtualized system that uses a handful of hypercalls, but mostly just uses virtio devices. It has no emulated real hardware (no 8250 UART, no emulated legacy anything...) Virtualization is useful for running legacy code. Why dismiss support for non pv guests so easily? How different MIPS SMP systems are? What about running non pv UP systems? David Daney On 06/07/2013 04:03 PM, David Daney wrote: From: David Daney david.da...@cavium.com These patches take a somewhat different approach to MIPS virtualization via the MIPS-VZ extensions than the patches previously sent by Sanjay Lal. Several facts about the code: o Existing exception handlers are modified to hook in to KVM instead of intercepting all exceptions via the EBase register, and then chaining to real exception handlers. o Able to boot 64-bit SMP guests that use the FPU (I have booted 4-way SMP 64-bit MIPS/Linux). o Additional overhead on every exception even when *no* vCPU is running. o Lower interrupt overhead, than the EBase interception method, when vCPU *is* running. o This code is somewhat smaller than the existing trap/emulate implementation (about 2100 lines vs. about 5300 lines) o Currently probably only usable on the OCTEON III CPU model, as some MIPS-VZ implementation-defined behaviors were assumed to have the OCTEON III behavior. Note: I think Ralf already has the 17/31 (MIPS: Quit exposing Kconfig symbols in uapi headers.) queued, but I also include it here. David Daney (31): MIPS: Move allocate_kscratch to cpu-probe.c and make it public. MIPS: Save and restore K0/K1 when CONFIG_KVM_MIPSVZ mips/kvm: Fix 32-bitisms in kvm_locore.S mips/kvm: Add casts to avoid pointer width mismatch build failures. mips/kvm: Use generic cache flushing functions. mips/kvm: Rename kvm_vcpu_arch.pc to kvm_vcpu_arch.epc mips/kvm: Rename VCPU_registername to KVM_VCPU_ARCH_registername mips/kvm: Fix code formatting in arch/mips/kvm/kvm_locore.S mips/kvm: Factor trap-and-emulate support into a pluggable implementation. mips/kvm: Implement ioctls to get and set FPU registers. MIPS: Rearrange branch.c so it can be used by kvm code. MIPS: Add instruction format information for WAIT, MTC0, MFC0, et al. mips/kvm: Add accessors for MIPS VZ registers. mips/kvm: Add thread_info flag to indicate operation in MIPS VZ Guest Mode. mips/kvm: Exception handling to leave and reenter guest mode. mips/kvm: Add exception handler for MIPSVZ Guest exceptions. MIPS: Quit exposing Kconfig symbols in uapi headers. mips/kvm: Add pt_regs slots for BadInstr and BadInstrP mips/kvm: Add host definitions for MIPS VZ based host. mips/kvm: Hook into TLB fault handlers. mips/kvm: Allow set_except_vector() to be used from MIPSVZ code. mips/kvm: Split get_new_mmu_context into two parts. mips/kvm: Hook into CP unusable exception handler. mips/kvm: Add thread_struct fields used by MIPSVZ hosts. mips/kvm: Add some asm-offsets constants used by MIPSVZ. mips/kvm: Split up Kconfig and Makefile definitions in preperation for MIPSVZ. mips/kvm: Gate the use of kvm_local_flush_tlb_all() by KVM_MIPSTE mips/kvm: Only use KVM_COALESCED_MMIO_PAGE_OFFSET with KVM_MIPSTE mips/kvm: Add MIPSVZ support. mips/kvm: Enable MIPSVZ in Kconfig/Makefile mips/kvm: Allow for upto 8 KVM vcpus per vm. arch/mips/Kconfig |1 + arch/mips/include/asm/branch.h |7 + arch/mips/include/asm/kvm_host.h| 622 +--- arch/mips/include/asm/kvm_mips_te.h | 589 +++ arch/mips/include/asm/kvm_mips_vz.h | 29 + arch/mips/include/asm/mipsregs.h| 264 + arch/mips/include/asm/mmu_context.h | 12 +- arch/mips/include/asm/processor.h |6 + arch/mips/include/asm/ptrace.h | 36 + arch/mips/include/asm/stackframe.h | 150 ++- arch/mips/include/asm/thread_info.h |2 + arch/mips/include/asm/uasm.h|2 +- arch/mips/include/uapi/asm/inst.h | 23 +- arch/mips/include/uapi/asm/ptrace.h | 17 +- arch/mips/kernel/asm-offsets.c | 124 ++- arch/mips/kernel/branch.c | 63 +- arch/mips/kernel/cpu-probe.c| 34 + arch/mips/kernel/genex.S|8 + arch/mips/kernel/scall64-64.S | 12 + arch/mips/kernel/scall64-n32.S | 12 + arch/mips/kernel/traps.c| 15 +- arch/mips/kvm/Kconfig | 23 +- arch/mips/kvm/Makefile | 15 +- arch/mips/kvm/kvm_locore.S | 980
Re: [PATCH 00/31] KVM/MIPS: Implement hardware virtualization via the MIPS-VZ extensions.
On 06/09/2013 12:31 AM, Gleb Natapov wrote: On Fri, Jun 07, 2013 at 04:15:00PM -0700, David Daney wrote: I should also add that I will shortly send patches for the kvm tool required to drive this VM as well as a small set of patches that create a para-virtualized MIPS/Linux guest kernel. The idea is that because there is no standard SMP linux system, we create a standard para-virtualized system that uses a handful of hypercalls, but mostly just uses virtio devices. It has no emulated real hardware (no 8250 UART, no emulated legacy anything...) Virtualization is useful for running legacy code. Why dismiss support for non pv guests so easily? Just because we create standard PV system devices, doesn't preclude emulating real hardware. In fact Sanjay Lal's work includes QEMU support for doing just this for a MIPS malta board. I just wanted a very simple system I could implement with the kvm tool in a couple of days, so that is what I initially did. The problem is that almost nobody has real malta boards, they are really only of interest because QEMU implements a virtual malta board. Personally, I see the most interesting us cases of MIPS KVM being a deployment platform for new services, so legacy support is not so important to me. That doesn't mean that other people wouldn't want some sort of legacy support. The problem with 'legacy' on MIPS is that there are hundreds of legacies to choose from (Old SGI and DEC hardware, various network hardware from many different vendors, etc.). Which would you choose? How different MIPS SMP systems are? o Old SGI heavy metal (several different system architectures). o Cavium OCTEON SMP SoCs. o Broadcom (several flavors) SoCs o Loongson Come to think of it, Emulating SGI hardware might be an interesting case. There may be old IRIX systems and applications that could be running low on real hardware. Some of those systems take up a whole room and draw a lot of power. They might run faster and at much lower power consumption on a modern 48-Way SMP SoC based system. What about running non pv UP systems? See above. I think this is what Sanjay Lal is doing. David Daney On 06/07/2013 04:03 PM, David Daney wrote: From: David Daney david.da...@cavium.com These patches take a somewhat different approach to MIPS virtualization via the MIPS-VZ extensions than the patches previously sent by Sanjay Lal. Several facts about the code: o Existing exception handlers are modified to hook in to KVM instead of intercepting all exceptions via the EBase register, and then chaining to real exception handlers. o Able to boot 64-bit SMP guests that use the FPU (I have booted 4-way SMP 64-bit MIPS/Linux). o Additional overhead on every exception even when *no* vCPU is running. o Lower interrupt overhead, than the EBase interception method, when vCPU *is* running. o This code is somewhat smaller than the existing trap/emulate implementation (about 2100 lines vs. about 5300 lines) o Currently probably only usable on the OCTEON III CPU model, as some MIPS-VZ implementation-defined behaviors were assumed to have the OCTEON III behavior. Note: I think Ralf already has the 17/31 (MIPS: Quit exposing Kconfig symbols in uapi headers.) queued, but I also include it here. David Daney (31): MIPS: Move allocate_kscratch to cpu-probe.c and make it public. MIPS: Save and restore K0/K1 when CONFIG_KVM_MIPSVZ mips/kvm: Fix 32-bitisms in kvm_locore.S mips/kvm: Add casts to avoid pointer width mismatch build failures. mips/kvm: Use generic cache flushing functions. mips/kvm: Rename kvm_vcpu_arch.pc to kvm_vcpu_arch.epc mips/kvm: Rename VCPU_registername to KVM_VCPU_ARCH_registername mips/kvm: Fix code formatting in arch/mips/kvm/kvm_locore.S mips/kvm: Factor trap-and-emulate support into a pluggable implementation. mips/kvm: Implement ioctls to get and set FPU registers. MIPS: Rearrange branch.c so it can be used by kvm code. MIPS: Add instruction format information for WAIT, MTC0, MFC0, et al. mips/kvm: Add accessors for MIPS VZ registers. mips/kvm: Add thread_info flag to indicate operation in MIPS VZ Guest Mode. mips/kvm: Exception handling to leave and reenter guest mode. mips/kvm: Add exception handler for MIPSVZ Guest exceptions. MIPS: Quit exposing Kconfig symbols in uapi headers. mips/kvm: Add pt_regs slots for BadInstr and BadInstrP mips/kvm: Add host definitions for MIPS VZ based host. mips/kvm: Hook into TLB fault handlers. mips/kvm: Allow set_except_vector() to be used from MIPSVZ code. mips/kvm: Split get_new_mmu_context into two parts. mips/kvm: Hook into CP unusable exception handler. mips/kvm: Add thread_struct fields used by MIPSVZ hosts. mips/kvm: Add some asm-offsets constants used by MIPSVZ. mips/kvm: Split up Kconfig and Makefile definitions in preperation for MIPSVZ. mips/kvm: Gate the use of
Re: [PATCH 00/31] KVM/MIPS: Implement hardware virtualization via the MIPS-VZ extensions.
On Sun, 9 Jun 2013, David Daney wrote: How different MIPS SMP systems are? o Old SGI heavy metal (several different system architectures). o Cavium OCTEON SMP SoCs. o Broadcom (several flavors) SoCs o Loongson o Old DEC hardware (DECsystem 58x0, R3000-based). o Malta-based MIPS Technologies CMP solutions (1004K, 1074K, interAptiv). Maciej -- 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 00/31] KVM/MIPS: Implement hardware virtualization via the MIPS-VZ extensions.
I should also add that I will shortly send patches for the kvm tool required to drive this VM as well as a small set of patches that create a para-virtualized MIPS/Linux guest kernel. The idea is that because there is no standard SMP linux system, we create a standard para-virtualized system that uses a handful of hypercalls, but mostly just uses virtio devices. It has no emulated real hardware (no 8250 UART, no emulated legacy anything...) David Daney On 06/07/2013 04:03 PM, David Daney wrote: From: David Daney david.da...@cavium.com These patches take a somewhat different approach to MIPS virtualization via the MIPS-VZ extensions than the patches previously sent by Sanjay Lal. Several facts about the code: o Existing exception handlers are modified to hook in to KVM instead of intercepting all exceptions via the EBase register, and then chaining to real exception handlers. o Able to boot 64-bit SMP guests that use the FPU (I have booted 4-way SMP 64-bit MIPS/Linux). o Additional overhead on every exception even when *no* vCPU is running. o Lower interrupt overhead, than the EBase interception method, when vCPU *is* running. o This code is somewhat smaller than the existing trap/emulate implementation (about 2100 lines vs. about 5300 lines) o Currently probably only usable on the OCTEON III CPU model, as some MIPS-VZ implementation-defined behaviors were assumed to have the OCTEON III behavior. Note: I think Ralf already has the 17/31 (MIPS: Quit exposing Kconfig symbols in uapi headers.) queued, but I also include it here. David Daney (31): MIPS: Move allocate_kscratch to cpu-probe.c and make it public. MIPS: Save and restore K0/K1 when CONFIG_KVM_MIPSVZ mips/kvm: Fix 32-bitisms in kvm_locore.S mips/kvm: Add casts to avoid pointer width mismatch build failures. mips/kvm: Use generic cache flushing functions. mips/kvm: Rename kvm_vcpu_arch.pc to kvm_vcpu_arch.epc mips/kvm: Rename VCPU_registername to KVM_VCPU_ARCH_registername mips/kvm: Fix code formatting in arch/mips/kvm/kvm_locore.S mips/kvm: Factor trap-and-emulate support into a pluggable implementation. mips/kvm: Implement ioctls to get and set FPU registers. MIPS: Rearrange branch.c so it can be used by kvm code. MIPS: Add instruction format information for WAIT, MTC0, MFC0, et al. mips/kvm: Add accessors for MIPS VZ registers. mips/kvm: Add thread_info flag to indicate operation in MIPS VZ Guest Mode. mips/kvm: Exception handling to leave and reenter guest mode. mips/kvm: Add exception handler for MIPSVZ Guest exceptions. MIPS: Quit exposing Kconfig symbols in uapi headers. mips/kvm: Add pt_regs slots for BadInstr and BadInstrP mips/kvm: Add host definitions for MIPS VZ based host. mips/kvm: Hook into TLB fault handlers. mips/kvm: Allow set_except_vector() to be used from MIPSVZ code. mips/kvm: Split get_new_mmu_context into two parts. mips/kvm: Hook into CP unusable exception handler. mips/kvm: Add thread_struct fields used by MIPSVZ hosts. mips/kvm: Add some asm-offsets constants used by MIPSVZ. mips/kvm: Split up Kconfig and Makefile definitions in preperation for MIPSVZ. mips/kvm: Gate the use of kvm_local_flush_tlb_all() by KVM_MIPSTE mips/kvm: Only use KVM_COALESCED_MMIO_PAGE_OFFSET with KVM_MIPSTE mips/kvm: Add MIPSVZ support. mips/kvm: Enable MIPSVZ in Kconfig/Makefile mips/kvm: Allow for upto 8 KVM vcpus per vm. arch/mips/Kconfig |1 + arch/mips/include/asm/branch.h |7 + arch/mips/include/asm/kvm_host.h| 622 +--- arch/mips/include/asm/kvm_mips_te.h | 589 +++ arch/mips/include/asm/kvm_mips_vz.h | 29 + arch/mips/include/asm/mipsregs.h| 264 + arch/mips/include/asm/mmu_context.h | 12 +- arch/mips/include/asm/processor.h |6 + arch/mips/include/asm/ptrace.h | 36 + arch/mips/include/asm/stackframe.h | 150 ++- arch/mips/include/asm/thread_info.h |2 + arch/mips/include/asm/uasm.h|2 +- arch/mips/include/uapi/asm/inst.h | 23 +- arch/mips/include/uapi/asm/ptrace.h | 17 +- arch/mips/kernel/asm-offsets.c | 124 ++- arch/mips/kernel/branch.c | 63 +- arch/mips/kernel/cpu-probe.c| 34 + arch/mips/kernel/genex.S|8 + arch/mips/kernel/scall64-64.S | 12 + arch/mips/kernel/scall64-n32.S | 12 + arch/mips/kernel/traps.c| 15 +- arch/mips/kvm/Kconfig | 23 +- arch/mips/kvm/Makefile | 15 +- arch/mips/kvm/kvm_locore.S | 980 +- arch/mips/kvm/kvm_mips.c| 768 ++ arch/mips/kvm/kvm_mips_comm.h |1 + arch/mips/kvm/kvm_mips_commpage.c |9 +- arch/mips/kvm/kvm_mips_dyntrans.c |4 +- arch/mips/kvm/kvm_mips_emul.c | 312 +++--- arch/mips/kvm/kvm_mips_int.c| 53 +-
[PATCH 00/31] KVM/MIPS: Implement hardware virtualization via the MIPS-VZ extensions.
From: David Daney david.da...@cavium.com These patches take a somewhat different approach to MIPS virtualization via the MIPS-VZ extensions than the patches previously sent by Sanjay Lal. Several facts about the code: o Existing exception handlers are modified to hook in to KVM instead of intercepting all exceptions via the EBase register, and then chaining to real exception handlers. o Able to boot 64-bit SMP guests that use the FPU (I have booted 4-way SMP 64-bit MIPS/Linux). o Additional overhead on every exception even when *no* vCPU is running. o Lower interrupt overhead, than the EBase interception method, when vCPU *is* running. o This code is somewhat smaller than the existing trap/emulate implementation (about 2100 lines vs. about 5300 lines) o Currently probably only usable on the OCTEON III CPU model, as some MIPS-VZ implementation-defined behaviors were assumed to have the OCTEON III behavior. Note: I think Ralf already has the 17/31 (MIPS: Quit exposing Kconfig symbols in uapi headers.) queued, but I also include it here. David Daney (31): MIPS: Move allocate_kscratch to cpu-probe.c and make it public. MIPS: Save and restore K0/K1 when CONFIG_KVM_MIPSVZ mips/kvm: Fix 32-bitisms in kvm_locore.S mips/kvm: Add casts to avoid pointer width mismatch build failures. mips/kvm: Use generic cache flushing functions. mips/kvm: Rename kvm_vcpu_arch.pc to kvm_vcpu_arch.epc mips/kvm: Rename VCPU_registername to KVM_VCPU_ARCH_registername mips/kvm: Fix code formatting in arch/mips/kvm/kvm_locore.S mips/kvm: Factor trap-and-emulate support into a pluggable implementation. mips/kvm: Implement ioctls to get and set FPU registers. MIPS: Rearrange branch.c so it can be used by kvm code. MIPS: Add instruction format information for WAIT, MTC0, MFC0, et al. mips/kvm: Add accessors for MIPS VZ registers. mips/kvm: Add thread_info flag to indicate operation in MIPS VZ Guest Mode. mips/kvm: Exception handling to leave and reenter guest mode. mips/kvm: Add exception handler for MIPSVZ Guest exceptions. MIPS: Quit exposing Kconfig symbols in uapi headers. mips/kvm: Add pt_regs slots for BadInstr and BadInstrP mips/kvm: Add host definitions for MIPS VZ based host. mips/kvm: Hook into TLB fault handlers. mips/kvm: Allow set_except_vector() to be used from MIPSVZ code. mips/kvm: Split get_new_mmu_context into two parts. mips/kvm: Hook into CP unusable exception handler. mips/kvm: Add thread_struct fields used by MIPSVZ hosts. mips/kvm: Add some asm-offsets constants used by MIPSVZ. mips/kvm: Split up Kconfig and Makefile definitions in preperation for MIPSVZ. mips/kvm: Gate the use of kvm_local_flush_tlb_all() by KVM_MIPSTE mips/kvm: Only use KVM_COALESCED_MMIO_PAGE_OFFSET with KVM_MIPSTE mips/kvm: Add MIPSVZ support. mips/kvm: Enable MIPSVZ in Kconfig/Makefile mips/kvm: Allow for upto 8 KVM vcpus per vm. arch/mips/Kconfig |1 + arch/mips/include/asm/branch.h |7 + arch/mips/include/asm/kvm_host.h| 622 +--- arch/mips/include/asm/kvm_mips_te.h | 589 +++ arch/mips/include/asm/kvm_mips_vz.h | 29 + arch/mips/include/asm/mipsregs.h| 264 + arch/mips/include/asm/mmu_context.h | 12 +- arch/mips/include/asm/processor.h |6 + arch/mips/include/asm/ptrace.h | 36 + arch/mips/include/asm/stackframe.h | 150 ++- arch/mips/include/asm/thread_info.h |2 + arch/mips/include/asm/uasm.h|2 +- arch/mips/include/uapi/asm/inst.h | 23 +- arch/mips/include/uapi/asm/ptrace.h | 17 +- arch/mips/kernel/asm-offsets.c | 124 ++- arch/mips/kernel/branch.c | 63 +- arch/mips/kernel/cpu-probe.c| 34 + arch/mips/kernel/genex.S|8 + arch/mips/kernel/scall64-64.S | 12 + arch/mips/kernel/scall64-n32.S | 12 + arch/mips/kernel/traps.c| 15 +- arch/mips/kvm/Kconfig | 23 +- arch/mips/kvm/Makefile | 15 +- arch/mips/kvm/kvm_locore.S | 980 +- arch/mips/kvm/kvm_mips.c| 768 ++ arch/mips/kvm/kvm_mips_comm.h |1 + arch/mips/kvm/kvm_mips_commpage.c |9 +- arch/mips/kvm/kvm_mips_dyntrans.c |4 +- arch/mips/kvm/kvm_mips_emul.c | 312 +++--- arch/mips/kvm/kvm_mips_int.c| 53 +- arch/mips/kvm/kvm_mips_int.h|2 - arch/mips/kvm/kvm_mips_stats.c |6 +- arch/mips/kvm/kvm_mipsvz.c | 1894 +++ arch/mips/kvm/kvm_mipsvz_guest.S| 234 + arch/mips/kvm/kvm_tlb.c | 140 +-- arch/mips/kvm/kvm_trap_emul.c | 932 +++-- arch/mips/mm/fault.c|8 + arch/mips/mm/tlbex-fault.S |6 + arch/mips/mm/tlbex.c| 45 +- 39 files changed, 5299 insertions(+), 2161 deletions(-) create mode 100644 arch/mips/include/asm/kvm_mips_te.h create mode
