> > > + /* VTCR_EL2 value for this VM */
> > > + u64vtcr;
> >
> > VTCR seems quite strongly tied to the MMU config. Is it not controlled
> > independently for the nested MMUs and so remains in this struct?
>
> This particular instance of VTCR_EL2 is the host's version. Which
> means it
> +#define __tlbi_level(op, addr, level)
> \
> + do {\
> + u64 arg = addr; \
> +
On Wed, Apr 22, 2020 at 01:00:29PM +0100, Marc Zyngier wrote:
> Advertise bits [58:55] as reserved for SW in the S2 descriptors.
>
> Signed-off-by: Marc Zyngier
> ---
> arch/arm64/include/asm/pgtable-hwdef.h | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git
From: Will Deacon
Changing CONFIG_KVM to be a 'menuconfig' entry in Kconfig mean that we
can straightforwardly enumerate optional features, such as the virtual
PMU device as dependent options.
Signed-off-by: Will Deacon
Signed-off-by: Fuad Tabba
---
arch/arm64/kvm/Kconfig | 16
From: Will Deacon
CONFIG_KVM_ARM_HOST is just a proxy for CONFIG_KVM, so remove it in favour
of the latter.
Signed-off-by: Will Deacon
Signed-off-by: Fuad Tabba
---
arch/arm64/kernel/asm-offsets.c | 2 +-
arch/arm64/kernel/cpu_errata.c | 2 +-
arch/arm64/kernel/smp.c | 2 +-
Hi,
This small patch series tidies up the arm64 KVM build system by
rejigging config options, removing some redundant help text, and
consolidating some of the Makefile rules.
The changes are cosmetic, but it seemed worthwhile to send this out
for consideration. This series is a refresh on top
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 +
arch/arm64/kvm/hyp/Makefile | 15 ---
2 files changed, 17
From: Will Deacon
arm64 KVM supports 16k pages since 02e0b7600f83
("arm64: kvm: Add support for 16K pages"), so update the Kconfig help
text accordingly.
Signed-off-by: Will Deacon
Signed-off-by: Fuad Tabba
---
arch/arm64/kvm/Kconfig | 2 --
1 file changed, 2 deletions(-)
diff --git
Having a go at reviewing. Might turn out to be more useful as a learning
exercise for me rather than useful feedback but we've got to start
somewhere..
> -struct kvm_arch {
> +struct kvm_s2_mmu {
> struct kvm_vmid vmid;
>
> - /* stage2 entry level table */
> - pgd_t *pgd;
> -
On Tue, 05 May 2020 18:23:51 +0100,
Andrew Scull wrote:
>
> > > > + /* VTCR_EL2 value for this VM */
> > > > + u64vtcr;
> > >
> > > VTCR seems quite strongly tied to the MMU config. Is it not controlled
> > > independently for the nested MMUs and so remains in this struct?
> >
Hi James,
On Tue, 05 May 2020 17:03:15 +0100,
James Morse wrote:
>
> Hi Marc,
>
> On 22/04/2020 13:00, Marc Zyngier wrote:
> > From: Christoffer Dall
> >
> > As we are about to reuse our stage 2 page table manipulation code for
> > shadow stage 2 page tables in the context of nested
Hi Andrew,
On Tue, 05 May 2020 16:26:48 +0100,
Andrew Scull wrote:
>
> Having a go at reviewing. Might turn out to be more useful as a learning
> exercise for me rather than useful feedback but we've got to start
> somewhere..
Thanks for making the effort. Asking questions is never a pointless
Hi Marc,
On 22/04/2020 13:00, Marc Zyngier wrote:
> From: Christoffer Dall
>
> As we are about to reuse our stage 2 page table manipulation code for
> shadow stage 2 page tables in the context of nested virtualization, we
> are going to manage multiple stage 2 page tables for a single VM.
>
>
On Tue, May 05, 2020 at 01:12:39PM +0100, Will Deacon wrote:
> On Tue, May 05, 2020 at 12:50:54PM +0100, Mark Rutland wrote:
> > On Tue, May 05, 2020 at 12:27:19PM +0100, Will Deacon wrote:
> > > On Tue, May 05, 2020 at 12:16:07PM +0100, Mark Rutland wrote:
> > > > On Tue, May 05, 2020 at
On Tue, May 05, 2020 at 12:50:54PM +0100, Mark Rutland wrote:
> On Tue, May 05, 2020 at 12:27:19PM +0100, Will Deacon wrote:
> > On Tue, May 05, 2020 at 12:16:07PM +0100, Mark Rutland wrote:
> > > On Tue, May 05, 2020 at 12:12:41PM +0100, Will Deacon wrote:
> > > > On Sat, May 02, 2020 at
On Tue, May 05, 2020 at 12:27:19PM +0100, Will Deacon wrote:
> On Tue, May 05, 2020 at 12:16:07PM +0100, Mark Rutland wrote:
> > On Tue, May 05, 2020 at 12:12:41PM +0100, Will Deacon wrote:
> > > On Sat, May 02, 2020 at 07:03:53PM +0530, Anshuman Khandual wrote:
> > > > This adds basic building
On Tue, May 05, 2020 at 12:16:07PM +0100, Mark Rutland wrote:
> On Tue, May 05, 2020 at 12:12:41PM +0100, Will Deacon wrote:
> > On Sat, May 02, 2020 at 07:03:53PM +0530, Anshuman Khandual wrote:
> > > This adds basic building blocks required for ID_PFR2 CPU register which
> > > provides
On Tue, May 05, 2020 at 12:16:07PM +0100, Mark Rutland wrote:
> On Tue, May 05, 2020 at 12:12:41PM +0100, Will Deacon wrote:
> > On Sat, May 02, 2020 at 07:03:53PM +0530, Anshuman Khandual wrote:
> > > This adds basic building blocks required for ID_PFR2 CPU register which
> > > provides
On Tue, May 05, 2020 at 12:12:41PM +0100, Will Deacon wrote:
> On Sat, May 02, 2020 at 07:03:53PM +0530, Anshuman Khandual wrote:
> > This adds basic building blocks required for ID_PFR2 CPU register which
> > provides information about the AArch32 programmers model which must be
> > interpreted
On Sat, May 02, 2020 at 07:03:53PM +0530, Anshuman Khandual wrote:
> This adds basic building blocks required for ID_PFR2 CPU register which
> provides information about the AArch32 programmers model which must be
> interpreted along with ID_PFR0 and ID_PFR1 CPU registers. This is added
> per ARM
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 same time. This
patch does a unified
Paolo Bonzini, any opinion on this?
Thanks and best,
Tianjia
On 2020/4/27 12: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
On 05/05/2020 02:03 AM, Will Deacon wrote:
> On Sat, May 02, 2020 at 07:03:55PM +0530, Anshuman Khandual wrote:
>> This adds basic building blocks required for ID_MMFR5 CPU register which
>> provides information about the implemented memory model and memory
>> management support in AArch32
23 matches
Mail list logo
