Re: [PATCH] KVM: arm/arm64: replacing per-VM's per-CPU variable

On Tue, 13 Mar 2018 19:33:55 +, Robin Murphy wrote: > > On 13/03/18 13:01, Marc Zyngier wrote: > > [You're repeatedly posting to the kvmarm mailing list without being > > subscribed to it. I've flushed the queue now, but please consider > > subscribing to the list, it will help everyone] > >

Re: [PATCH] KVM: arm/arm64: replacing per-VM's per-CPU variable

On 13/03/18 13:01, Marc Zyngier wrote: [You're repeatedly posting to the kvmarm mailing list without being subscribed to it. I've flushed the queue now, but please consider subscribing to the list, it will help everyone] On 13/03/18 21:03, Peng Hao wrote: Using a global per-CPU variable

Re: [PATCH] KVM: arm/arm64: replacing per-VM's per-CPU variable

[You're repeatedly posting to the kvmarm mailing list without being subscribed to it. I've flushed the queue now, but please consider subscribing to the list, it will help everyone] On 13/03/18 21:03, Peng Hao wrote: > Using a global per-CPU variable instead of per-VM's per-CPU variable. > >

[PATCH] KVM: arm/arm64: replacing per-VM's per-CPU variable

Using a global per-CPU variable instead of per-VM's per-CPU variable. Signed-off-by: Peng Hao --- arch/arm/include/asm/kvm_host.h | 3 --- arch/arm64/include/asm/kvm_host.h | 3 --- virt/kvm/arm/arm.c| 26 ++ 3 files changed, 6

Re: [PATCH v5 14/23] arm64: KVM: Introduce EL2 VA randomisation

[Resending with Marc's email address fixed, looks like I miss-operated the mouse and pasted some stray text in the address...] Hi Marc, On 01/03/18 15:55, Marc Zyngier wrote: > The main idea behind randomising the EL2 VA is that we usually have > a few spare bits between the most significant bit

Re: [PATCH v5 09/23] KVM: arm/arm64: Keep GICv2 HYP VAs in kvm_vgic_global_state

On 13/03/18 09:35, Suzuki K Poulose wrote: > On 01/03/18 15:55, Marc Zyngier wrote: >> As we're about to change the way we map devices at HYP, we need >> to move away from kern_hyp_va on an IO address. >> >> One way of achieving this is to store the VAs in kvm_vgic_global_state, >> and use that

Re: [PATCH v5 14/23] arm64: KVM: Introduce EL2 VA randomisation

Hi Marc, On 01/03/18 15:55, Marc Zyngier wrote: > The main idea behind randomising the EL2 VA is that we usually have > a few spare bits between the most significant bit of the VA mask > and the most significant bit of the linear mapping. > > Those bits could be a bunch of zeroes, and could be

Re: [PATCH v5 22/23] arm64: KVM: Allow mapping of vectors outside of the RAM region

On Tue, Mar 13, 2018 at 10:30:12AM +, Marc Zyngier wrote: > >> + > >> +if (cpus_have_const_cap(ARM64_HARDEN_BRANCH_PREDICTOR)) { > > > > Moving the create_hyp_mappings() under this cap check looks like a fix > > that could be posted separately? > > We could. Not sure that's a big deal

Re: [PATCH v5 22/23] arm64: KVM: Allow mapping of vectors outside of the RAM region

Hi Drew, On 08/03/18 17:54, Andrew Jones wrote: > On Thu, Mar 01, 2018 at 03:55:37PM +, Marc Zyngier wrote: >> We're now ready to map our vectors in weird and wonderful locations. >> On enabling ARM64_HARDEN_EL2_VECTORS, a vector slots gets allocated >> if this hasn't been already done via

Re: [PATCH v5 09/23] KVM: arm/arm64: Keep GICv2 HYP VAs in kvm_vgic_global_state

On 01/03/18 15:55, Marc Zyngier wrote: As we're about to change the way we map devices at HYP, we need to move away from kern_hyp_va on an IO address. One way of achieving this is to store the VAs in kvm_vgic_global_state, and use that directly from the HYP code. This requires a small change to

Re: [PATCH v5 08/23] KVM: arm/arm64: Move ioremap calls to create_hyp_io_mappings

On 01/03/18 15:55, Marc Zyngier wrote: Both HYP io mappings call ioremap, followed by create_hyp_io_mappings. Let's move the ioremap call into create_hyp_io_mappings itself, which simplifies the code a bit and allows for further refactoring. Reviewed-by: Christoffer Dall

Re: [PATCH v5 05/23] arm64: cpufeatures: Drop the ARM64_HYP_OFFSET_LOW feature flag

On 01/03/18 15:55, Marc Zyngier wrote: Now that we can dynamically compute the kernek/hyp VA mask, there is no need for a feature flag to trigger the alternative patching. Let's drop the flag and everything that depends on it. Acked-by: Christoffer Dall