Re: [GIT PULL] KVM/arm64 updates for 6.2

2022-12-06 Thread Marc Zyngier
On Tue, 06 Dec 2022 21:43:43 +, Paolo Bonzini wrote: > > On 12/6/22 19:20, Mark Brown wrote: > >> I almost suggested doing that on multiple occasions this cycle, but > >> ultimately > >> decided not to because it would effectively mean splitting series that > >> touch KVM > >> and

Re: [GIT PULL] KVM/arm64 updates for 6.2

2022-12-06 Thread Paolo Bonzini
On 12/6/22 19:20, Mark Brown wrote: I almost suggested doing that on multiple occasions this cycle, but ultimately decided not to because it would effectively mean splitting series that touch KVM and selftests into different trees, which would create a different kind of dependency hell. Or

Re: [GIT PULL] KVM/arm64 updates for 6.2

2022-12-06 Thread Marc Zyngier
On Tue, 06 Dec 2022 17:41:21 +, Paolo Bonzini wrote: > > On 12/5/22 16:58, Marc Zyngier wrote: > > - There is a lot of selftest conflicts with your own branch, see: > > > >https://lore.kernel.org/r/20221201112432.4cb9a...@canb.auug.org.au > >

Re: [GIT PULL] KVM/arm64 updates for 6.2

2022-12-06 Thread Mark Brown
On Tue, Dec 06, 2022 at 06:10:32PM +, Sean Christopherson wrote: > Alternatively, we could have a dedicated selftests/kvm tree (or branch)? > I almost suggested doing that on multiple occasions this cycle, but ultimately > decided not to because it would effectively mean splitting series

Re: [GIT PULL] KVM/arm64 updates for 6.2

2022-12-06 Thread Sean Christopherson
On Tue, Dec 06, 2022, Paolo Bonzini wrote: > On 12/5/22 16:58, Marc Zyngier wrote: > > - There is a lot of selftest conflicts with your own branch, see: > > > >https://lore.kernel.org/r/20221201112432.4cb9a...@canb.auug.org.au > >

Re: [GIT PULL] KVM/arm64 updates for 6.2

2022-12-06 Thread Paolo Bonzini
On 12/5/22 16:58, Marc Zyngier wrote: - There is a lot of selftest conflicts with your own branch, see: https://lore.kernel.org/r/20221201112432.4cb9a...@canb.auug.org.au https://lore.kernel.org/r/20221201113626.438f1...@canb.auug.org.au

Re: [PATCH v3 7/8] perf: Add perf_event_attr::config3

2022-12-06 Thread Mark Rutland
Peter, it looks like this series is blocked on the below now; what would you prefer out of: (a) Take this as is, and look add adding additional validation on top. (b) Add some flag to indicate a PMU driver supports config3, and have the core code check that, but leave the existing fields

[PATCH v1 12/12] KVM: arm64: Allow guests with >48-bit IPA size on FEAT_LPA2 systems

2022-12-06 Thread Ryan Roberts
With all the page-table infrastructure in place, we can finally increase the maximum permisable IPA size to 52-bits on 4KB and 16KB page systems that have FEAT_LPA2. Signed-off-by: Ryan Roberts --- arch/arm64/kvm/reset.c | 11 +-- 1 file changed, 5 insertions(+), 6 deletions(-) diff

[PATCH v1 09/12] KVM: arm64: Convert translation level parameter to s8

2022-12-06 Thread Ryan Roberts
With the introduction of FEAT_LPA2, the Arm ARM adds a new level of translation, level -1, so levels can now be in the range [-1;3]. 3 is always the last level and the first level is determined based on the number of VA bits in use. Convert level variables to use a signed type in preparation for

[PATCH v1 10/12] KVM: arm64: Rework logic to en/decode VTCR_EL2.{SL0, SL2} fields

2022-12-06 Thread Ryan Roberts
In order to support 5 level translation, FEAT_LPA2 introduces the 1-bit SL2 field within VTCR_EL2 to extend the existing 2-bit SL0 field. The SL2[0]:SL0[1:0] encodings have no simple algorithmic relationship to the start levels they represent (that I can find, at least), so replace the existing

[PATCH v1 11/12] KVM: arm64: Support upto 5 levels of translation in kvm_pgtable

2022-12-06 Thread Ryan Roberts
FEAT_LPA2 increases the maximum levels of translation from 4 to 5 for the 4KB page case, when IA is >48 bits. While we can still use 4 levels for stage2 translation in this case (due to stage2 allowing concatenated page tables for first level lookup), the same kvm_pgtable library is used for the

[PATCH v1 08/12] KVM: arm64: Insert PS field at TCR_EL2 assembly time

2022-12-06 Thread Ryan Roberts
With the addition of LPA2 support in the hypervisor, the PA size supported by the HW must be capped with a runtime decision, rather than simply using a compile-time decision based on PA_BITS.For example, on a system that advertises 52 bit PA but does not support FEAT_LPA2, A 4KB or 16KB kernel

[PATCH v1 04/12] KVM: arm64: Plumbing to enable multiple pgtable formats

2022-12-06 Thread Ryan Roberts
FEAT_LPA2 brings support for 52-bit input and output addresses for both stage1 and stage2 translation when using 4KB and 16KB page sizes. The architecture allows for the HW to support FEAT_LPA2 in one or both stages of translation. When FEAT_LPA2 is enabled for a given stage, it effectively

[PATCH v1 05/12] KVM: arm64: Maintain page-table format info in struct kvm_pgtable

2022-12-06 Thread Ryan Roberts
As the next step on the journey to supporting FEAT_LPA2 in KVM, add a flag to struct kvm_pgtable, which functions can then use to select the approprate behavior for either the `classic` or `lpa2` page-table formats. For now, all page-tables remain in the `classic` format. No functional changes

[PATCH v1 06/12] KVM: arm64: Use LPA2 page-tables for stage2 if HW supports it

2022-12-06 Thread Ryan Roberts
Implement a simple policy whereby if the HW supports FEAT_LPA2 for the page size we are using, always use LPA2-style page-tables for stage 2, regardless of the VMM-requested IPA size or HW-implemented PA size. When in use we can now support up to 52-bit IPA and PA sizes. We use the preparitory

[PATCH v1 07/12] KVM: arm64: Use LPA2 page-tables for hyp stage1 if HW supports it

2022-12-06 Thread Ryan Roberts
Implement a simple policy whereby if the HW supports FEAT_LPA2 for the page size we are using, always use LPA2-style page-tables for hyp stage 1, regardless of the IPA or PA size requirements. When in use we can now support up to 52-bit IPA and PA sizes. For the protected kvm case, the host

[PATCH v1 01/12] arm64/mm: Add FEAT_LPA2 specific ID_AA64MMFR0.TGRAN[2]

2022-12-06 Thread Ryan Roberts
From: Anshuman Khandual PAGE_SIZE support is tested against possible minimum and maximum values for its respective ID_AA64MMFR0.TGRAN field, depending on whether it is signed or unsigned. But then FEAT_LPA2 implementation needs to be validated for 4K and 16K page sizes via feature specific

[PATCH v1 03/12] KVM: arm64: Add new (V)TCR_EL2 field definitions for FEAT_LPA2

2022-12-06 Thread Ryan Roberts
As per Arm ARM (0487I.a), (V)TCR_EL2.DS fields control whether 52 bit input and output addresses are supported on 4K and 16K page size configurations when FEAT_LPA2 is known to have been implemented. Additionally, VTCR_EL2.SL2 field is added to enable encoding of a 5th starting level of

[PATCH v1 02/12] arm64/mm: Update tlb invalidation routines for FEAT_LPA2

2022-12-06 Thread Ryan Roberts
FEAT_LPA2 impacts tlb invalidation in 2 ways; Firstly, the TTL field in the non-range tlbi instructions can now validly take a 0 value for the 4KB granule (this is due to the extra level of translation). Secondly, the BADDR field in the range tlbi instructions must be aligned to 64KB when LPA2 is

[PATCH v1 00/12] KVM: arm64: Support FEAT_LPA2 at hyp s1 and vm s2

2022-12-06 Thread Ryan Roberts
(appologies, I'm resending this series as I managed to send the cover letter to all but the following patches only to myself on first attempt). This is my first upstream feature submission so please go easy ;-) Add support for FEAT_LPA2 to KVM for both hypervisor stage 1 (for the nvhe/protected

Re: [PATCH v1 00/12] KVM: arm64: Support FEAT_LPA2 at hyp s1 and vm s2

2022-12-06 Thread Marc Zyngier
On Tue, 06 Dec 2022 12:06:00 +, Ryan Roberts wrote: > > This is my first upstream feature submission so please go easy ;-) Sure! Where are the patches? ;-) M. -- Without deviation from the norm, progress is not possible. ___ kvmarm

[PATCH v1 00/12] KVM: arm64: Support FEAT_LPA2 at hyp s1 and vm s2

2022-12-06 Thread Ryan Roberts
This is my first upstream feature submission so please go easy ;-) Add support for FEAT_LPA2 to KVM for both hypervisor stage 1 (for the nvhe/protected modes) and the vm stage 2 translation tables. FEAT_LPA2 enables 52 bit PAs and VAs for 4KB and 16KB granules (note this is already supported for