This validates hypervisor capabilities like VMID width, IPA range for any
hot plug CPU against system finalized values. While here, it factors out
get_vmid_bits() for general use and also defines ID_AA64MMFR0_PARANGE_MASK.
Cc: Catalin Marinas
Cc: Will Deacon
Cc: Marc Zyngier
Cc: Mark Rutland
> @@ -176,7 +177,7 @@ static void clear_stage2_pud_entry(struct kvm_s2_mmu
> *mmu, pud_t *pud, phys_addr
> pmd_t *pmd_table __maybe_unused = stage2_pmd_offset(kvm, pud, 0);
> VM_BUG_ON(stage2_pud_huge(kvm, *pud));
> stage2_pud_clear(kvm, pud);
> - kvm_tlb_flush_vmid_ipa(mmu,
> -void __hyp_text __kvm_tlb_flush_vmid_ipa(struct kvm_s2_mmu *mmu, phys_addr_t
> ipa)
> +void __hyp_text __kvm_tlb_flush_vmid_ipa(struct kvm_s2_mmu *mmu,
> + phys_addr_t ipa, int level)
The level feels like a good opportunity for an enum to add some
On Thursday 07 May 2020 at 15:01:07 (+0100), Marc Zyngier wrote:
> > /*
> > - * u64 __kvm_call_hyp(void *hypfn, ...);
> > + * u64 __kvm_call_hyp(unsigned long arg, ...);
> > *
> > * This is not really a variadic function in the classic C-way and care
> > must
> > * be taken when calling
Hi Marc,
>
> What breaks without this constraint? Is it a fix that should go in
> early? Otherwise looks good.
This only becomes an issue when __hyp_call_panic_nvhe() and
__hyp_call_panic_vhe() are moved to separate files, so I don't think it's
necessary to go in early.
Currently the string
Hey Marc,
On Thursday 07 May 2020 at 14:10:30 (+0100), Marc Zyngier wrote:
> Hi David, Quentin,
>
> On Thu, 30 Apr 2020 15:48:18 +0100,
> David Brazdil wrote:
> >
> > From: Quentin Perret
> >
> > In preparation for removing the hyp code from the TCB, convert the current
>
> nit: Unless we
Hi Marc, Christoffer,
On 22/04/2020 13:00, Marc Zyngier wrote:
> From: Christoffer Dall
>
> If we move the used_lrs field to the version-specific cpu interface
> structure, the following functions only operate on the struct
> vgic_v3_cpu_if and not the full vcpu:
>
> __vgic_v3_save_state
>
Hi,
On Thu, May 07, 2020 at 02:16:56PM +0200, Marek Szyprowski wrote:
> Hi
>
> On 14.04.2020 17:34, Mike Rapoport wrote:
> > From: Mike Rapoport
> >
> > Implement primitives necessary for the 4th level folding, add walks of p4d
> > level where appropriate, and remove __ARCH_USE_5LEVEL_HACK.
> >
On 2020-05-07 16:07, Marc Zyngier wrote:
On Thu, 30 Apr 2020 15:48:21 +0100,
David Brazdil wrote:
[...]
hyp-entry.S contains implementation of KVM hyp vectors. This code is
mostly
shared between VHE/nVHE, therefore compile it under both VHE and nVHE
build
rules, with small differences
On 2020-05-07 16:08, Andrew Scull wrote:
-void __hyp_text __kvm_tlb_flush_vmid_ipa(struct kvm_s2_mmu *mmu,
phys_addr_t ipa)
+void __hyp_text __kvm_tlb_flush_vmid_ipa(struct kvm_s2_mmu *mmu,
+phys_addr_t ipa, int level)
The level feels like a good
On Thu, 30 Apr 2020 15:48:21 +0100,
David Brazdil wrote:
>
> This patch is part of a series which builds KVM's non-VHE hyp code separately
> from VHE and the rest of the kernel.
This sentence should be part of your cover letter, and not in the 5th
patch.
>
> hyp-entry.S contains
On 05/07/2020 03:50 PM, Marc Zyngier wrote:
> On Thu, 7 May 2020 11:49:47 +0530
> Anshuman Khandual wrote:
>
> Hi Anshuman,
Hi Marc,
>
>> This validates KVM capabilities like VMID width, IPA range for hotplug CPU
>> against system finalized values. While here, it factors out
On Thu, 30 Apr 2020 15:48:17 +0100,
David Brazdil wrote:
>
> From: Quentin Perret
>
> Currently, the arm64 KVM code provides __kvm_call_hyp assembly procedure which
> does nothing but call the HVC instruction. This is used to call functions by
> their pointer in EL2 under nVHE, and abused by
On Tue, May 05, 2020 at 04:45:20PM +0100, Fuad Tabba wrote:
> Consolidate references to the CONFIG_KVM configuration item to encompass
> entire folders rather than per line.
>
> Signed-off-by: Fuad Tabba
> ---
> arch/arm64/kvm/Makefile | 38 +
>
On Thu, 30 Apr 2020 15:48:20 +0100,
David Brazdil wrote:
>
> Add new folder arch/arm64/kvm/hyp/nvhe and a Makefile for building code that
s/folder/directory/
> runs in EL2 under nVHE KVM.
>
> Compile each source file into a `.hyp.tmp.o` object first, then prefix all
> its symbols with
On Thu, 30 Apr 2020 15:48:19 +0100,
David Brazdil wrote:
>
> __hyp_call_panic_nvhe contains inline assembly which did not declare
> its dependency on the __hyp_panic_string symbol.
>
> Signed-off-by: David Brazdil
> ---
> arch/arm64/kvm/hyp/switch.c | 2 +-
> 1 file changed, 1 insertion(+), 1
On 2020/5/5 16:39, Marc Zyngier wrote:
Hi Tianjia,
On 2020-04-27 05:35, Tianjia Zhang wrote:
In the current kvm version, 'kvm_run' has been included in the 'kvm_vcpu'
structure. For historical reasons, many kvm-related function parameters
retain the 'kvm_run' and 'kvm_vcpu' parameters at the
Hi David, Quentin,
On Thu, 30 Apr 2020 15:48:18 +0100,
David Brazdil wrote:
>
> From: Quentin Perret
>
> In preparation for removing the hyp code from the TCB, convert the current
nit: Unless we have a different interpretation of the TCB acronym, I
think you want to remove anything *but* the
From: Suzuki K Poulose
If we are checking whether the stage2 can map PAGE_SIZE,
we don't have to do the boundary checks as both the host
VMA and the guest memslots are page aligned. Bail the case
easily.
While we're at it, fixup a typo in the comment below.
Cc: Christoffer Dall
Cc: Marc
This series was originally posted by Suzuki K Poulose a year ago [*],
with the aim of cleaning up the handling of the stage2 huge mapping for
THP. I think this still helps to make the current code cleaner, so
rebase it on top of kvmarm/master and repost it for acceptance.
Thanks!
[*]
From: Suzuki K Poulose
We support mapping host memory backed by PMD transparent hugepages
at stage2 as huge pages. However the checks are now spread across
two different places. Let us unify the handling of the THPs to
keep the code cleaner (and future proof for PUD THP support).
This patch
Hi
On 14.04.2020 17:34, Mike Rapoport wrote:
> From: Mike Rapoport
>
> Implement primitives necessary for the 4th level folding, add walks of p4d
> level where appropriate, and remove __ARCH_USE_5LEVEL_HACK.
>
> Signed-off-by: Mike Rapoport
Today I've noticed that kexec is broken on ARM 32bit.
Hi,
On 4/22/20 1:00 PM, Marc Zyngier wrote:
> With ARMv8.5-GTG, the hardware (or more likely a hypervisor) can
> advertise the supported Stage-2 page sizes.
>
> Let's check this at boot time.
>
> Signed-off-by: Marc Zyngier
> ---
> arch/arm64/include/asm/kvm_host.h | 2 +-
>
On 04/15/2020 09:42 AM, Jiang Yi wrote:
Do cond_resched_lock() in stage2_flush_memslot() like what is done in
unmap_stage2_range() and other places holding mmu_lock while processing
a possibly large range of memory.
Signed-off-by: Jiang Yi
---
virt/kvm/arm/mmu.c | 3 +++
1 file changed, 3
On Thu, 7 May 2020 11:49:47 +0530
Anshuman Khandual wrote:
Hi Anshuman,
> This validates KVM capabilities like VMID width, IPA range for hotplug CPU
> against system finalized values. While here, it factors out get_vmid_bits()
> for general use and also defines ID_AA64MMFR0_PARANGE_MASK.
nit:
Hi Shameer,
On 5/7/20 8:59 AM, Shameerali Kolothum Thodi wrote:
> Hi Eric,
>
>> -Original Message-
>> From: Shameerali Kolothum Thodi
>> Sent: 30 April 2020 10:38
>> To: 'Auger Eric' ; Zhangfei Gao
>> ; eric.auger@gmail.com;
>> io...@lists.linux-foundation.org;
Hi Eric,
> -Original Message-
> From: Shameerali Kolothum Thodi
> Sent: 30 April 2020 10:38
> To: 'Auger Eric' ; Zhangfei Gao
> ; eric.auger@gmail.com;
> io...@lists.linux-foundation.org; linux-ker...@vger.kernel.org;
> k...@vger.kernel.org; kvmarm@lists.cs.columbia.edu;
This validates KVM capabilities like VMID width, IPA range for hotplug CPU
against system finalized values. While here, it factors out get_vmid_bits()
for general use and also defines ID_AA64MMFR0_PARANGE_MASK.
Cc: Catalin Marinas
Cc: Will Deacon
Cc: Marc Zyngier
Cc: Mark Rutland
Cc: James
28 matches
Mail list logo
