Re: [RFC 54/55] KVM: arm/arm64: Adjust virtual offset considering nesting

Hi Jintack, On Mon, Jan 09, 2017 at 01:24:50AM -0500, Jintack Lim wrote: > The guest hypervisor sets cntvoff_el2 for its VM (i.e. nested VM). Note > that physical/virtual counter value in the guest hypervisor's point of > view is already offsetted by the virtual offset set by the host >

Re: [RFC 00/55] Nested Virtualization on KVM/ARM

Hi Jintack, On Mon, Jan 09, 2017 at 01:23:56AM -0500, Jintack Lim wrote: > Nested virtualization is the ability to run a virtual machine inside another > virtual machine. In other words, it’s about running a hypervisor (the guest > hypervisor) on top of another hypervisor (the host hypervisor).

Re: [RFC 47/55] KVM: arm/arm64: Forward the guest hypervisor's stage 2 permission faults

On Mon, Jan 09, 2017 at 01:24:43AM -0500, Jintack Lim wrote: > From: Christoffer Dall > > When faulting on a shadow stage 2 page table we have to check if the > fault was a permission fault and if so, if that fault needs to be > handled by the guest hypervisor before

Re: [RFC 41/55] KVM: arm/arm64: Unmap/flush shadow stage 2 page tables

On Mon, Jan 09, 2017 at 01:24:37AM -0500, Jintack Lim wrote: > From: Christoffer Dall > > Unmap/flush shadow stage 2 page tables for the nested VMs as well as the > stage 2 page table for the guest hypervisor. > > Note: A bunch of the code in mmu.c relating to MMU

Re: [RFC 40/55] KVM: arm/arm64: Handle vttbr_el2 write operation from the guest hypervisor

On Mon, Jan 09, 2017 at 01:24:36AM -0500, Jintack Lim wrote: > Each nested VM is supposed to have a mmu (i.e. shadow stage-2 page to have a 'struct kvm_mmu' ? > table), and we create it when the guest hypervisor writes to vttbr_el2 > with a new vmid. I think the commit message should also

Re: [PATCH] KVM: arm/arm64: vgic-v3: Don't pretend to support IRQ/FIQ bypass

Hi Marc, On 22/02/2017 13:13, Marc Zyngier wrote: > Our GICv3 emulation always presents ICC_SRE_EL1 with DIB/DFB set to > zero, which implies that there is a way to bypass the GIC and > inject raw IRQ/FIQ by driving the CPU pins. > > Of course, we don't allow that when the GIC is configured, but

Re: [RFC 35/55] KVM: arm/arm64: Support mmu for the virtual EL2 execution

On Mon, Jan 09, 2017 at 01:24:31AM -0500, Jintack Lim wrote: > From: Christoffer Dall > > When running a guest hypervisor in virtual EL2, the translation context > has to be separate from the rest of the system, including the guest > EL1/0 translation regime, so we

Re: [RFC 39/55] KVM: arm/arm64: Add mmu context for the nesting

On Mon, Jan 09, 2017 at 01:24:35AM -0500, Jintack Lim wrote: > Add the shadow stage-2 MMU context to be used for the nesting, but don't > do anything with it yet. > > The host hypervisor maintains mmu structures for each nested VM. When > entering a nested VM, the host hypervisor searches for the

Re: [RFC 32/55] KVM: arm/arm64: register GICH iodev for the guest hypervisor

On Mon, Jan 09, 2017 at 01:24:28AM -0500, Jintack Lim wrote: > Register a device for the virtual interface control block(GICH) access > from the guest hypervisor. > > TODO: Get GICH address from DT, which is hardcoded now. > It's not so much about the DT as it is adding an API for userspace to

Re: [RFC 31/55] KVM: arm/arm64: Inject maintenance interrupts to the guest hypervisor

On Mon, Jan 09, 2017 at 01:24:27AM -0500, Jintack Lim wrote: > From: Christoffer Dall > > If we exit a nested VM with a pending maintenance interrupt from the > GIC, then we need to forward this to the guest hypervisor so that it can > re-sync the appropriate LRs and

Re: [RFC 30/55] KVM: arm/arm64: Inject irqs to the guest hypervisor

On Mon, Jan 09, 2017 at 01:24:26AM -0500, Jintack Lim wrote: > If we have a pending IRQ for the guest and the guest expects IRQs > to be handled in its virtual EL2 mode (the virtual IMO bit is set) > and it is not already running in virtual EL2 mode, then we have to > emulate an IRQ exception. >

Re: [RFC 28/55] KVM: arm/arm64: Prepare vgic state for the nested VM

On Mon, Jan 09, 2017 at 01:24:24AM -0500, Jintack Lim wrote: > When entering a nested VM, we set up the hypervisor control interface > based on what the guest hypervisor has set. Especially, we investigate > each list register written by the guest hypervisor whether HW bit is > set. If so, we

Re: [RFC 27/55] KVM: arm/arm64: Emulate GICH interface on GICv2

On Mon, Jan 09, 2017 at 01:24:23AM -0500, Jintack Lim wrote: > Emulate GICH interface accesses from the guest hypervisor. > > Signed-off-by: Jintack Lim > Signed-off-by: Shih-Wei Li > Signed-off-by: Christoffer Dall

[PATCH] KVM: arm/arm64: vgic-v3: Don't pretend to support IRQ/FIQ bypass

Our GICv3 emulation always presents ICC_SRE_EL1 with DIB/DFB set to zero, which implies that there is a way to bypass the GIC and inject raw IRQ/FIQ by driving the CPU pins. Of course, we don't allow that when the GIC is configured, but we fail to indicate that to the guest. The obvious fix is to

Re: [RFC 21/55] KVM: arm64: Forward HVC instruction to the guest hypervisor

On Mon, Jan 09, 2017 at 01:24:17AM -0500, Jintack Lim wrote: > Forward exceptions due to hvc instruction to the guest hypervisor. > > Signed-off-by: Jintack Lim > --- > arch/arm64/include/asm/kvm_nested.h | 5 + > arch/arm64/kvm/Makefile | 1 + >

[PATCH 7/8] arm64: KVM: pmu: Make illegal accesses seen as successfully emulated

Now that we can deliver an exception on an illegal PMU access, we can stop pretending that they have failed to be emulated. We can thus return "true" in all these cases. Signed-off-by: Marc Zyngier --- arch/arm64/kvm/sys_regs.c | 30 +++--- 1 file

[PATCH 3/8] arm64: KVM: Refactor pmu_*_el0_disabled

There is a lot of duplication in the pmu_*_el0_disabled helpers, and as we're going to modify them shortly, let's move all the common stuff in a single function. No functionnal change. Signed-off-by: Marc Zyngier --- arch/arm64/kvm/sys_regs.c | 25

[PATCH 2/8] arm64: KVM: Let the vcpu carry a pointer to the sys_reg being emulated

In order to be able to propagate the pointer to the sys_reg descriptor being currently emulated without having to rewrite a lot of the sys_reg handling, let's allow the vcpu structure to have a pointer to the current sys_reg_params. The pointer is set in a helper function that calls the trap

[PATCH 1/8] arm64: KVM: Don't skip an instruction if an exception is pending

When a trapping instruction has been successfully emulated, we skip it in order to start executing the following one. Any change in the PC made while handling the trap (such as injecting an exception) is going to completely wreck the execution of the guest by skiping an instruction that hasn't

[PATCH 8/8] arm64: KVM: Do not corrupt registers on failed 64bit CP read

If we fail to emulate a mrrc instruction, we: 1) deliver an exception, 2) spit a nastygram on the console, 3) write back some garbage to Rt/Rt2 While 1) and 2) are perfectly acceptable, 3) is out of the scope of the architecture... Let's mimick the code in kvm_handle_cp_32 and be more cautious.

[PATCH 5/8] arm64: KVM: PMU: Inject UNDEF on non-privileged accesses

access_pminten() and access_pmuserenr() can only be accessed when the CPU is in a priviledged mode. If it is not, let's inject an UNDEF exception. Signed-off-by: Marc Zyngier --- arch/arm64/kvm/sys_regs.c | 12 1 file changed, 8 insertions(+), 4 deletions(-)

[PATCH 6/8] arm64: KVM: PMU: Inject UNDEF on read access to PMSWINC_EL0

PMSWINC_EL0 is a WO register, so let's UNDEF when reading from it. Signed-off-by: Marc Zyngier --- arch/arm64/kvm/sys_regs.c | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm64/kvm/sys_regs.c b/arch/arm64/kvm/sys_regs.c index cbe966658d5e..01c8d841851e 100644

Re: [RFC 18/55] KVM: arm64: Forward traps due to HCR_EL2.NV1 bit to the guest hypervisor

On Mon, Jan 09, 2017 at 01:24:14AM -0500, Jintack Lim wrote: > Forward ELR_EL1, SPSR_EL1 and VBAR_EL1 traps to the guest hypervisor if > it has set the NV1 bit to the virtual HCR_EL2. The guest hypervisor > would set this NV1 bit to run a hypervisor in its VM (i.e. another level > of nested

Re: [RFC 17/55] KVM: arm64: Trap SPSR_EL1, ELR_EL1 and VBAR_EL1 in virtual EL2

On Mon, Jan 09, 2017 at 01:24:13AM -0500, Jintack Lim wrote: > For the same reason we trap virtual memory register accesses in virtual > EL2, we need to trap SPSR_EL1, ELR_EL1 and VBAR_EL1 accesses. ARM v8.3 > introduces the HCR_EL2.NV1 bit to be able to trap on those register > accesses in EL1.

Re: [RFC 16/55] KVM: arm64: Forward VM reg traps to the guest hypervisor

On Mon, Jan 09, 2017 at 01:24:12AM -0500, Jintack Lim wrote: > Forward virtual memory register traps to the guest hypervisor > if it has set corresponding bits to the virtual HCR_EL2. I was a bit confused about the subject of this patch. I would recommend calling it something like "Respect

Re: [RFC 14/55] KVM: arm64: Take account of system instruction traps

On Mon, Jan 09, 2017 at 01:24:10AM -0500, Jintack Lim wrote: > When HCR.NV bit is set, execution of the EL2 translation regime Address > Translation instructions and TLB maintenance instructions are trapped to > EL2. In addition, execution of the EL1 translation regime Address > Translation

Re: [RFC 12/55] KVM: arm64: Handle EL2 register access traps

On Mon, Jan 09, 2017 at 01:24:08AM -0500, Jintack Lim wrote: > ARM v8.3 introduces a new bit in the HCR_EL2, which is the NV bit. When > this bit is set, accessing EL2 registers in EL1 traps to EL2. In > addition, executing following instructions in EL1 will trap to EL2 - > tlbi and at

Re: [RFC 12/55] KVM: arm64: Handle EL2 register access traps

On Mon, Jan 09, 2017 at 01:24:08AM -0500, Jintack Lim wrote: > ARM v8.3 introduces a new bit in the HCR_EL2, which is the NV bit. When > this bit is set, accessing EL2 registers in EL1 traps to EL2. In > addition, executing following instructions in EL1 will trap to EL2 - the following: So these

Re: [RFC 11/55] KVM: arm64: Emulate taking an exception to the guest hypervisor

On Mon, Jan 09, 2017 at 01:24:07AM -0500, Jintack Lim wrote: > Emulate taking an exception to the guest hypervisor running in the > virtual EL2 as described in ARM ARM AArch64.TakeException(). I would rename the subject and change the description of this patch to talk about injecting exceptions

Re: [RFC 09/55] KVM: arm64: Set shadow EL1 registers for virtual EL2 execution

On Mon, Jan 09, 2017 at 01:24:05AM -0500, Jintack Lim wrote: > From: Christoffer Dall > > When entering virtual EL2, we need to reflect virtual EL2 register > states to corresponding shadow EL1 registers. We can simply copy them if > their formats are identical.

Re: [RFC 08/55] KVM: arm64: Set virtual EL2 context depending on the guest exception level

On Mon, Jan 09, 2017 at 01:24:04AM -0500, Jintack Lim wrote: > From: Christoffer Dall > > Set up virutal EL2 context to hardware if the guest exception level is > EL2. > > Signed-off-by: Christoffer Dall > Signed-off-by: Jintack Lim

Re: [RFC 07/55] KVM: arm/arm64: Add virtual EL2 state emulation framework

On Mon, Jan 09, 2017 at 01:24:03AM -0500, Jintack Lim wrote: > From: Christoffer Dall > > Add a framework to set up the guest's context depending on the guest's > exception level. A chosen context is written to hardware in the lowvisor. > We don't set the virtual EL2

Re: [RFC 06/55] KVM: arm64: Add EL2 execution context for nesting

On Mon, Jan 09, 2017 at 01:24:02AM -0500, Jintack Lim wrote: > With the nested virtualization support, the context of the guest > includes EL2 register states. The host manages a set of virtual EL2 > registers. In addition to that, the guest hypervisor supposed to run in > EL2 is now deprivilaged

Re: [PATCH V10 07/10] efi: print unrecognized CPER section

On 22/02/17 01:12, Russell King - ARM Linux wrote: > On Tue, Feb 21, 2017 at 07:10:11PM +, James Morse wrote: >> Hi Tyler, >> >> On 15/02/17 19:51, Tyler Baicar wrote: >>> + } else { >>> + const void *unknown_err; >>> + >>> + unknown_err =