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]
> >
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 instead
[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.
>
> Sign
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 insertions(+), 26 deleti
[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
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 dir
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 us
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 tho
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 ARM
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
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
Signed-off-by: Marc Zyn
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
Signed-off-by: Marc Zyngier
---
arch/a
12 matches
Mail list logo
