Hi Jean,
> -Original Message-
> From: Jean-Philippe Brucker [mailto:jean-phili...@linaro.org]
> Sent: 04 March 2021 17:11
> To: Shameerali Kolothum Thodi
> Cc: linux-arm-ker...@lists.infradead.org; io...@lists.linux-foundation.org;
> kvmarm@lists.cs.columbia.edu; m...@kernel.org;
>
Hi,
On Tue, Feb 23, 2021 at 10:06:15PM +0100, Eric Auger wrote:
> This patch adds the VFIO_IOMMU_SET_MSI_BINDING ioctl which aim
> to (un)register the guest MSI binding to the host. This latter
> then can use those stage 1 bindings to build a nested stage
> binding targeting the physical MSIs.
On Fri, 05 Mar 2021 02:38:17 +,
Sami Tolvanen wrote:
>
> On Thu, Mar 4, 2021 at 2:34 PM Sami Tolvanen wrote:
> >
> > On Thu, Mar 4, 2021 at 2:17 PM Marc Zyngier wrote:
> > >
> > > On Thu, 04 Mar 2021 21:25:41 +,
> > > Sami Tolvanen wrote:
[...]
> > > > I assume hyp_panic() ends up
On Fri, 05 Mar 2021 10:34:25 +,
Yejune Deng wrote:
>
> In big.LITTLE architecture,the application layer calls KVM_ARM_VCPU_INIT
> several times.Sometimes the thread will run on the big core, sometimes
> will run on the little core.The big core and the little core has always
> different
On Thursday 04 Mar 2021 at 19:25:41 (+), Will Deacon wrote:
> > +static int do_pkvm_init(u32 hyp_va_bits)
> > +{
> > + void *per_cpu_base = kvm_ksym_ref(kvm_arm_hyp_percpu_base);
> > + int ret;
> > +
> > + preempt_disable();
> > + hyp_install_host_vector();
>
> It's a shame we need
On Thursday 04 Mar 2021 at 19:49:53 (+), Will Deacon wrote:
> On Tue, Mar 02, 2021 at 02:59:54PM +, Quentin Perret wrote:
> > Extend the memory pool allocated for the hypervisor to include enough
> > pages to map all of memory at page granularity for the host stage 2.
> > While at it, also
On Thursday 04 Mar 2021 at 20:03:36 (+), Will Deacon wrote:
> On Tue, Mar 02, 2021 at 02:59:57PM +, Quentin Perret wrote:
> > In order to ease its re-use in other code paths, refactor
> > stage2_map_set_prot_attr() to not depend on a stage2_map_data struct.
> > No functional change
On Thursday 04 Mar 2021 at 20:00:45 (+), Will Deacon wrote:
> On Tue, Mar 02, 2021 at 02:59:56PM +, Quentin Perret wrote:
> > Once we start unmapping portions of memory from the host stage 2 (such
> > as e.g. the hypervisor memory sections, or pages that belong to
> > protected guests), we
On Fri, 5 Mar 2021 at 12:38, Marc Zyngier wrote:
>
> On Fri, 05 Mar 2021 02:38:17 +,
> Sami Tolvanen wrote:
> >
> > On Thu, Mar 4, 2021 at 2:34 PM Sami Tolvanen
> > wrote:
> > >
> > > On Thu, Mar 4, 2021 at 2:17 PM Marc Zyngier wrote:
> > > >
> > > > On Thu, 04 Mar 2021 21:25:41 +,
>
From: James Morse
As per ARM ARM DDI 0487G.a, when FEAT_LPA2 is implemented, ID_AA64MMFR0_EL1
might contain a range of values to describe supported translation granules
(4K and 16K pages sizes in particular) instead of just enabled or disabled
values. This changes __enable_mmu() function to
On Tue, Mar 02, 2021 at 02:59:58PM +, Quentin Perret wrote:
> Add a new map function to the KVM page-table library that allows to
> greedily create block identity-mappings. This will be useful to create
> lazily the host stage 2 page-table as it will own most of memory and
> will always be
On Fri, Mar 05, 2021 at 08:06:09PM +0530, Anshuman Khandual wrote:
> From: James Morse
>
> As per ARM ARM DDI 0487G.a, when FEAT_LPA2 is implemented, ID_AA64MMFR0_EL1
> might contain a range of values to describe supported translation granules
> (4K and 16K pages sizes in particular) instead of
Hi Paolo,
Here's the first batch of fixes for 5.12. We have a handful of low
level world-switch regressions, a page table walker fix, more PMU
tidying up, and a workaround for systems with creative firmware.
Note that this is based on -rc1 despite the breakage, as I didn't feel
like holding
On Fri, Mar 05, 2021 at 03:03:36PM +, Quentin Perret wrote:
> On Friday 05 Mar 2021 at 14:39:42 (+), Will Deacon wrote:
> > On Tue, Mar 02, 2021 at 02:59:58PM +, Quentin Perret wrote:
> > > + /* Reduce the kvm_mem_range to a granule size */
> > > + ret = __stage2_reduce_range(,
On 2021-03-05 16:55, Sami Tolvanen wrote:
On Fri, Mar 5, 2021 at 6:22 AM Ard Biesheuvel wrote:
On Fri, 5 Mar 2021 at 12:38, Marc Zyngier wrote:
>
> On Fri, 05 Mar 2021 02:38:17 +,
> Sami Tolvanen wrote:
> >
> > On Thu, Mar 4, 2021 at 2:34 PM Sami Tolvanen
wrote:
> > >
> > > On Thu,
On 05/03/21 17:49, Marc Zyngier wrote:
Hi Paolo,
Here's the first batch of fixes for 5.12. We have a handful of low
level world-switch regressions, a page table walker fix, more PMU
tidying up, and a workaround for systems with creative firmware.
Note that this is based on -rc1 despite the
Hi Paolo,
On Fri, 05 Mar 2021 17:27:36 +,
Paolo Bonzini wrote:
>
> On 05/03/21 17:49, Marc Zyngier wrote:
> > Hi Paolo,
> >
> > Here's the first batch of fixes for 5.12. We have a handful of low
> > level world-switch regressions, a page table walker fix, more PMU
> > tidying up, and a
From: Suzuki K Poulose
The nVHE KVM hyp drains and disables the SPE buffer, before
entering the guest, as the EL1&0 translation regime
is going to be loaded with that of the guest.
But this operation is performed way too late, because :
- The owning translation regime of the SPE buffer
is
Hi Paolo,
Here's the first batch of fixes for 5.12. We have a handful of low
level world-switch regressions, a page table walker fix, more PMU
tidying up, and a workaround for systems with creative firmware.
This will need to go on top of the current state of mainline.
Please apply,
M.
From: Andrew Scull
When panicking from the nVHE hyp and restoring the host context, x29 is
expected to hold a pointer to the host context. This wasn't being done
so fix it to make sure there's a valid pointer the host context being
used.
Rather than passing a boolean indicating whether or not
We currently find out about the presence of a HW PMU (or the handling
of that PMU by perf, which amounts to the same thing) in a fairly
roundabout way, by checking the number of counters available to perf.
That's good enough for now, but we will soon need to find about about
that on paths where
When running under a nesting hypervisor, it isn't guaranteed that
the virtual HW will include a PMU. In which case, let's not try
to access the PMU registers in the world switch, as that'd be
deadly.
Reported-by: Andre Przywara
Signed-off-by: Marc Zyngier
Reviewed-by: Alexandru Elisei
Link:
As we are about to report a bit more information to the rest of
the kernel, rename __vgic_v3_get_ich_vtr_el2() to the more
explicit __vgic_v3_get_gic_config().
No functional change.
Tested-by: Shameer Kolothum
Signed-off-by: Marc Zyngier
---
arch/arm64/include/asm/kvm_asm.h | 4 ++--
It looks like we have broken firmware out there that wrongly advertises
a GICv2 compatibility interface, despite the CPUs not being able to deal
with it.
To work around this, check that the CPU initialising KVM is actually able
to switch to MMIO instead of system registers, and use that as a
From: Will Deacon
Commit 7db21530479f ("KVM: arm64: Restore hyp when panicking in guest
context") tracks the currently running vCPU, clearing the pointer to
NULL on exit from a guest.
Unfortunately, the use of 'set_loaded_vcpu' clobbers x1 to point at the
kvm_hyp_ctxt instead of the vCPU
From: Jia He
When walking the page tables at a given level, and if the start
address for the range isn't aligned for that level, we propagate
the misalignment on each iteration at that level.
This results in the walker ignoring a number of entries (depending
on the original misalignment) on
In big.LITTLE architecture,the application layer calls KVM_ARM_VCPU_INIT
several times.Sometimes the thread will run on the big core, sometimes
will run on the little core.The big core and the little core has always
different cpuid, but the init target is fixed. and that leads to
init->target !=
On Tue, Mar 02, 2021 at 03:00:01PM +, Quentin Perret wrote:
> The host currently writes directly in EL2 per-CPU data sections from
> the PMU code when running in nVHE. In preparation for unmapping the EL2
> sections from the host stage 2, disable PMU support in protected mode as
> we currently
On Friday 05 Mar 2021 at 14:39:42 (+), Will Deacon wrote:
> On Tue, Mar 02, 2021 at 02:59:58PM +, Quentin Perret wrote:
> > +/**
> > + * kvm_pgtable_stage2_idmap_greedy() - Identity-map an Intermediate
> > Physical
> > + *Address with a leaf entry at the
On Fri, Mar 05, 2021 at 09:52:12AM +, Quentin Perret wrote:
> On Thursday 04 Mar 2021 at 20:00:45 (+), Will Deacon wrote:
> > On Tue, Mar 02, 2021 at 02:59:56PM +, Quentin Perret wrote:
> > > Once we start unmapping portions of memory from the host stage 2 (such
> > > as e.g. the
On Wed, Mar 03, 2021 at 04:45:05PM +, Marc Zyngier wrote:
> It recently became apparent that the ARMv8 architecture has interesting
> rules regarding attributes being used when fetching instructions
> if the MMU is off at Stage-1.
>
> In this situation, the CPU is allowed to fetch from the
On Tue, Mar 02, 2021 at 03:00:02PM +, Quentin Perret wrote:
> When KVM runs in nVHE protected mode, use the host stage 2 to unmap the
> hypervisor sections. The long-term goal is to ensure the EL2 code can
> remain robust regardless of the host's state, so this starts by making
> sure the host
On Tue, Mar 02, 2021 at 02:59:59PM +, Quentin Perret wrote:
> When KVM runs in protected nVHE mode, make use of a stage 2 page-table
> to give the hypervisor some control over the host memory accesses. The
> host stage 2 is created lazily using large block mappings if possible,
> and will
On Fri, Mar 05, 2021 at 12:21:24PM -0800, Sami Tolvanen wrote:
> allmodconfig + CONFIG_LTO_CLANG_THIN=y fails to build due to following
> linker errors:
>
> ld.lld: error: irqbypass.c:(function __guest_enter: .text+0x21CC):
> relocation R_AARCH64_CONDBR19 out of range: 2031220 is not in
>
On Fri, Mar 5, 2021 at 6:22 AM Ard Biesheuvel wrote:
>
> On Fri, 5 Mar 2021 at 12:38, Marc Zyngier wrote:
> >
> > On Fri, 05 Mar 2021 02:38:17 +,
> > Sami Tolvanen wrote:
> > >
> > > On Thu, Mar 4, 2021 at 2:34 PM Sami Tolvanen
> > > wrote:
> > > >
> > > > On Thu, Mar 4, 2021 at 2:17 PM
On Thu, Mar 4, 2021 at 2:34 PM Sami Tolvanen wrote:
>
> On Thu, Mar 4, 2021 at 2:17 PM Marc Zyngier wrote:
> >
> > On Thu, 04 Mar 2021 21:25:41 +,
> > Sami Tolvanen wrote:
> > >
> > > On Thu, Mar 4, 2021 at 11:15 AM Marc Zyngier wrote:
> > > >
> > > > On Thu, 04 Mar 2021 18:45:44 +,
>
On Thu, Mar 4, 2021 at 2:17 PM Marc Zyngier wrote:
>
> On Thu, 04 Mar 2021 21:25:41 +,
> Sami Tolvanen wrote:
> >
> > On Thu, Mar 4, 2021 at 11:15 AM Marc Zyngier wrote:
> > >
> > > On Thu, 04 Mar 2021 18:45:44 +,
> > > Sami Tolvanen wrote:
> > > >
> > > > allmodconfig +
37 matches
Mail list logo
