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
>
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).
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
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
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
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
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
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
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
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
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.
>
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
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
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
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 +
>
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
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
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
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
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.
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(-)
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
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
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.
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
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
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
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
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
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.
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
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
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
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 =
34 matches
Mail list logo