All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andrew Scull <ascull@google.com>
To: Marc Zyngier <maz@kernel.org>
Cc: linux-arm-kernel@lists.infradead.org,
	kvmarm@lists.cs.columbia.edu, kvm@vger.kernel.org,
	Will Deacon <will@kernel.org>,
	Andre Przywara <andre.przywara@arm.com>,
	Dave Martin <Dave.Martin@arm.com>,
	George Cherian <gcherian@marvell.com>,
	"Zengtao (B)" <prime.zeng@hisilicon.com>,
	Catalin Marinas <catalin.marinas@arm.com>
Subject: Re: [PATCH 03/26] KVM: arm64: Factor out stage 2 page table data from struct kvm
Date: Tue, 5 May 2020 18:23:51 +0100	[thread overview]
Message-ID: <20200505172351.GD237572@google.com> (raw)
In-Reply-To: <86pnbitka5.wl-maz@kernel.org>

> > > +	/* VTCR_EL2 value for this VM */
> > > +	u64    vtcr;
> > 
> > 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 describes the virtual HW for the EL1 guest. It constraints,
> among other things, the number of IPA bits for the guest, for example,
> and is configured by the VMM.
> 
> Once you start nesting, each vcpu has its own VTCR_EL2 which is still
> constrained by the main one (no nested guest can have a T0SZ bigger
> than the value imposed by userspace for this guest as a whole).
> 
> Does it make sense?

It does up to my ignorance of the spec in this regard.

Simliar to James's question, should `vtcr` live inside the mmu struct
with the top level `kvm::mmu` field containing the host's version and
the nested mmus containing the nested version of vtcr to be applied to
the vCPU? I didn't noticed there being a vtcr for the nested version in
the ~90-patch series so maybe that just isn't something that needs
thinking about?

WARNING: multiple messages have this Message-ID (diff)
From: Andrew Scull <ascull@google.com>
To: Marc Zyngier <maz@kernel.org>
Cc: kvm@vger.kernel.org, Andre Przywara <andre.przywara@arm.com>,
	kvmarm@lists.cs.columbia.edu,
	George Cherian <gcherian@marvell.com>,
	"Zengtao \(B\)" <prime.zeng@hisilicon.com>,
	Catalin Marinas <catalin.marinas@arm.com>,
	Will Deacon <will@kernel.org>, Dave Martin <Dave.Martin@arm.com>,
	linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH 03/26] KVM: arm64: Factor out stage 2 page table data from struct kvm
Date: Tue, 5 May 2020 18:23:51 +0100	[thread overview]
Message-ID: <20200505172351.GD237572@google.com> (raw)
In-Reply-To: <86pnbitka5.wl-maz@kernel.org>

> > > +	/* VTCR_EL2 value for this VM */
> > > +	u64    vtcr;
> > 
> > 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 describes the virtual HW for the EL1 guest. It constraints,
> among other things, the number of IPA bits for the guest, for example,
> and is configured by the VMM.
> 
> Once you start nesting, each vcpu has its own VTCR_EL2 which is still
> constrained by the main one (no nested guest can have a T0SZ bigger
> than the value imposed by userspace for this guest as a whole).
> 
> Does it make sense?

It does up to my ignorance of the spec in this regard.

Simliar to James's question, should `vtcr` live inside the mmu struct
with the top level `kvm::mmu` field containing the host's version and
the nested mmus containing the nested version of vtcr to be applied to
the vCPU? I didn't noticed there being a vtcr for the nested version in
the ~90-patch series so maybe that just isn't something that needs
thinking about?
_______________________________________________
kvmarm mailing list
kvmarm@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm

WARNING: multiple messages have this Message-ID (diff)
From: Andrew Scull <ascull@google.com>
To: Marc Zyngier <maz@kernel.org>
Cc: kvm@vger.kernel.org, Andre Przywara <andre.przywara@arm.com>,
	kvmarm@lists.cs.columbia.edu,
	George Cherian <gcherian@marvell.com>,
	"Zengtao \(B\)" <prime.zeng@hisilicon.com>,
	Catalin Marinas <catalin.marinas@arm.com>,
	Will Deacon <will@kernel.org>, Dave Martin <Dave.Martin@arm.com>,
	linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH 03/26] KVM: arm64: Factor out stage 2 page table data from struct kvm
Date: Tue, 5 May 2020 18:23:51 +0100	[thread overview]
Message-ID: <20200505172351.GD237572@google.com> (raw)
In-Reply-To: <86pnbitka5.wl-maz@kernel.org>

> > > +	/* VTCR_EL2 value for this VM */
> > > +	u64    vtcr;
> > 
> > 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 describes the virtual HW for the EL1 guest. It constraints,
> among other things, the number of IPA bits for the guest, for example,
> and is configured by the VMM.
> 
> Once you start nesting, each vcpu has its own VTCR_EL2 which is still
> constrained by the main one (no nested guest can have a T0SZ bigger
> than the value imposed by userspace for this guest as a whole).
> 
> Does it make sense?

It does up to my ignorance of the spec in this regard.

Simliar to James's question, should `vtcr` live inside the mmu struct
with the top level `kvm::mmu` field containing the host's version and
the nested mmus containing the nested version of vtcr to be applied to
the vCPU? I didn't noticed there being a vtcr for the nested version in
the ~90-patch series so maybe that just isn't something that needs
thinking about?

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

  reply	other threads:[~2020-05-05 17:24 UTC|newest]

Thread overview: 234+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-04-22 12:00 [PATCH 00/26] KVM: arm64: Preliminary NV patches Marc Zyngier
2020-04-22 12:00 ` Marc Zyngier
2020-04-22 12:00 ` Marc Zyngier
2020-04-22 12:00 ` [PATCH 01/26] KVM: arm64: Check advertised Stage-2 page size capability Marc Zyngier
2020-04-22 12:00   ` Marc Zyngier
2020-04-22 12:00   ` Marc Zyngier
2020-04-22 13:40   ` Suzuki K Poulose
2020-04-22 13:40     ` Suzuki K Poulose
2020-04-22 13:40     ` Suzuki K Poulose
2020-04-22 14:07     ` Marc Zyngier
2020-04-22 14:07       ` Marc Zyngier
2020-04-22 14:07       ` Marc Zyngier
2020-04-22 14:14       ` Suzuki K Poulose
2020-04-22 14:14         ` Suzuki K Poulose
2020-04-22 14:14         ` Suzuki K Poulose
2020-05-07 11:42   ` Alexandru Elisei
2020-05-07 11:42     ` Alexandru Elisei
2020-05-07 11:42     ` Alexandru Elisei
2020-04-22 12:00 ` [PATCH 02/26] KVM: arm64: Move __load_guest_stage2 to kvm_mmu.h Marc Zyngier
2020-04-22 12:00   ` Marc Zyngier
2020-04-22 12:00   ` Marc Zyngier
2020-04-22 13:51   ` Suzuki K Poulose
2020-04-22 13:51     ` Suzuki K Poulose
2020-04-22 13:51     ` Suzuki K Poulose
2020-04-22 13:59     ` Marc Zyngier
2020-04-22 13:59       ` Marc Zyngier
2020-04-22 13:59       ` Marc Zyngier
2020-04-22 12:00 ` [PATCH 03/26] KVM: arm64: Factor out stage 2 page table data from struct kvm Marc Zyngier
2020-04-22 12:00   ` Marc Zyngier
2020-04-22 12:00   ` Marc Zyngier
2020-05-05 15:26   ` Andrew Scull
2020-05-05 15:26     ` Andrew Scull
2020-05-05 15:26     ` Andrew Scull
2020-05-05 16:32     ` Marc Zyngier
2020-05-05 16:32       ` Marc Zyngier
2020-05-05 16:32       ` Marc Zyngier
2020-05-05 17:23       ` Andrew Scull [this message]
2020-05-05 17:23         ` Andrew Scull
2020-05-05 17:23         ` Andrew Scull
2020-05-05 18:10         ` Marc Zyngier
2020-05-05 18:10           ` Marc Zyngier
2020-05-05 18:10           ` Marc Zyngier
2020-05-05 16:03   ` James Morse
2020-05-05 16:03     ` James Morse
2020-05-05 16:03     ` James Morse
2020-05-05 17:59     ` Marc Zyngier
2020-05-05 17:59       ` Marc Zyngier
2020-05-05 17:59       ` Marc Zyngier
2020-05-06  9:30       ` Marc Zyngier
2020-05-06  9:30         ` Marc Zyngier
2020-05-06  9:30         ` Marc Zyngier
2020-05-11 16:38   ` Alexandru Elisei
2020-05-11 16:38     ` Alexandru Elisei
2020-05-11 16:38     ` Alexandru Elisei
2020-05-12 11:17     ` James Morse
2020-05-12 11:17       ` James Morse
2020-05-12 11:17       ` James Morse
2020-05-12 15:47       ` Alexandru Elisei
2020-05-12 15:47         ` Alexandru Elisei
2020-05-12 15:47         ` Alexandru Elisei
2020-05-12 16:13         ` James Morse
2020-05-12 16:13           ` James Morse
2020-05-12 16:13           ` James Morse
2020-05-12 16:53       ` Alexandru Elisei
2020-05-12 16:53         ` Alexandru Elisei
2020-05-12 16:53         ` Alexandru Elisei
2020-05-27  8:41         ` Marc Zyngier
2020-05-27  8:41           ` Marc Zyngier
2020-05-27  8:41           ` Marc Zyngier
2020-05-27  8:45           ` Alexandru Elisei
2020-05-27  8:45             ` Alexandru Elisei
2020-05-27  8:45             ` Alexandru Elisei
2020-04-22 12:00 ` [PATCH 04/26] arm64: Detect the ARMv8.4 TTL feature Marc Zyngier
2020-04-22 12:00   ` Marc Zyngier
2020-04-22 12:00   ` Marc Zyngier
2020-04-27 15:55   ` Suzuki K Poulose
2020-04-27 15:55     ` Suzuki K Poulose
2020-04-27 15:55     ` Suzuki K Poulose
2020-04-22 12:00 ` [PATCH 05/26] arm64: Document SW reserved PTE/PMD bits in Stage-2 descriptors Marc Zyngier
2020-04-22 12:00   ` Marc Zyngier
2020-04-22 12:00   ` Marc Zyngier
2020-05-05 15:59   ` Andrew Scull
2020-05-05 15:59     ` Andrew Scull
2020-05-05 15:59     ` Andrew Scull
2020-05-06  9:39     ` Marc Zyngier
2020-05-06  9:39       ` Marc Zyngier
2020-05-06  9:39       ` Marc Zyngier
2020-05-06 10:11       ` Andrew Scull
2020-05-06 10:11         ` Andrew Scull
2020-05-06 10:11         ` Andrew Scull
2020-04-22 12:00 ` [PATCH 06/26] arm64: Add level-hinted TLB invalidation helper Marc Zyngier
2020-04-22 12:00   ` Marc Zyngier
2020-04-22 12:00   ` Marc Zyngier
2020-05-05 17:16   ` Andrew Scull
2020-05-05 17:16     ` Andrew Scull
2020-05-05 17:16     ` Andrew Scull
2020-05-06  8:05     ` Marc Zyngier
2020-05-06  8:05       ` Marc Zyngier
2020-05-06  8:05       ` Marc Zyngier
2020-04-22 12:00 ` [PATCH 07/26] KVM: arm64: Add a level hint to __kvm_tlb_flush_vmid_ipa Marc Zyngier
2020-04-22 12:00   ` Marc Zyngier
2020-04-22 12:00   ` Marc Zyngier
2020-05-07 15:08   ` Andrew Scull
2020-05-07 15:08     ` Andrew Scull
2020-05-07 15:08     ` Andrew Scull
2020-05-07 15:13     ` Marc Zyngier
2020-05-07 15:13       ` Marc Zyngier
2020-05-07 15:13       ` Marc Zyngier
2020-04-22 12:00 ` [PATCH 08/26] KVM: arm64: Use TTL hint in when invalidating stage-2 translations Marc Zyngier
2020-04-22 12:00   ` Marc Zyngier
2020-04-22 12:00   ` Marc Zyngier
2020-05-07 15:13   ` Andrew Scull
2020-05-07 15:13     ` Andrew Scull
2020-05-07 15:13     ` Andrew Scull
2020-05-12 12:04     ` James Morse
2020-05-12 12:04       ` James Morse
2020-05-12 12:04       ` James Morse
2020-05-13  9:06       ` Andrew Scull
2020-05-13  9:06         ` Andrew Scull
2020-05-13  9:06         ` Andrew Scull
2020-05-27  8:59         ` Marc Zyngier
2020-05-27  8:59           ` Marc Zyngier
2020-05-27  8:59           ` Marc Zyngier
2020-05-12 17:26   ` James Morse
2020-05-12 17:26     ` James Morse
2020-05-12 17:26     ` James Morse
2020-04-22 12:00 ` [PATCH 09/26] KVM: arm64: vgic-v3: Take cpu_if pointer directly instead of vcpu Marc Zyngier
2020-04-22 12:00   ` Marc Zyngier
2020-04-22 12:00   ` Marc Zyngier
2020-05-07 16:26   ` James Morse
2020-05-07 16:26     ` James Morse
2020-05-07 16:26     ` James Morse
2020-05-08 12:20     ` Marc Zyngier
2020-05-08 12:20       ` Marc Zyngier
2020-05-08 12:20       ` Marc Zyngier
2020-04-22 12:00 ` [PATCH 10/26] KVM: arm64: Refactor vcpu_{read,write}_sys_reg Marc Zyngier
2020-04-22 12:00   ` Marc Zyngier
2020-04-22 12:00   ` Marc Zyngier
2020-05-26 16:28   ` James Morse
2020-05-26 16:28     ` James Morse
2020-05-26 16:28     ` James Morse
2020-05-27 10:04     ` Marc Zyngier
2020-05-27 10:04       ` Marc Zyngier
2020-05-27 10:04       ` Marc Zyngier
2020-04-22 12:00 ` [PATCH 11/26] KVM: arm64: Add missing reset handlers for PMU emulation Marc Zyngier
2020-04-22 12:00   ` Marc Zyngier
2020-04-22 12:00   ` Marc Zyngier
2020-05-26 16:29   ` James Morse
2020-05-26 16:29     ` James Morse
2020-05-26 16:29     ` James Morse
2020-04-22 12:00 ` [PATCH 12/26] KVM: arm64: Move sysreg reset check to boot time Marc Zyngier
2020-04-22 12:00   ` Marc Zyngier
2020-04-22 12:00   ` Marc Zyngier
2020-04-22 12:00 ` [PATCH 13/26] KVM: arm64: Introduce accessor for ctxt->sys_reg Marc Zyngier
2020-04-22 12:00   ` Marc Zyngier
2020-04-22 12:00   ` Marc Zyngier
2020-04-22 12:00 ` [PATCH 14/26] KVM: arm64: hyp: Use ctxt_sys_reg/__vcpu_sys_reg instead of raw sys_regs access Marc Zyngier
2020-04-22 12:00   ` Marc Zyngier
2020-04-22 12:00   ` Marc Zyngier
2020-04-22 12:00 ` [PATCH 15/26] KVM: arm64: sve: Use __vcpu_sys_reg() " Marc Zyngier
2020-04-22 12:00   ` Marc Zyngier
2020-04-22 12:00   ` Marc Zyngier
2020-04-22 12:00 ` [PATCH 16/26] KVM: arm64: pauth: Use ctxt_sys_reg() " Marc Zyngier
2020-04-22 12:00   ` Marc Zyngier
2020-04-22 12:00   ` Marc Zyngier
2020-04-22 12:00 ` [PATCH 17/26] KVM: arm64: debug: " Marc Zyngier
2020-04-22 12:00   ` Marc Zyngier
2020-04-22 12:00   ` Marc Zyngier
2020-04-22 12:00 ` [PATCH 18/26] KVM: arm64: Don't use empty structures as CPU reset state Marc Zyngier
2020-04-22 12:00   ` Marc Zyngier
2020-04-22 12:00   ` Marc Zyngier
2020-04-24  4:07   ` Zenghui Yu
2020-04-24  4:07     ` Zenghui Yu
2020-04-24  4:07     ` Zenghui Yu
2020-04-24  7:45     ` Marc Zyngier
2020-04-24  7:45       ` Marc Zyngier
2020-04-24  7:45       ` Marc Zyngier
2020-04-28  1:34       ` Zengtao (B)
2020-04-28  1:34         ` Zengtao (B)
2020-04-28  1:34         ` Zengtao (B)
2020-04-22 12:00 ` [PATCH 19/26] KVM: arm64: Make struct kvm_regs userspace-only Marc Zyngier
2020-04-22 12:00   ` Marc Zyngier
2020-04-22 12:00   ` Marc Zyngier
2020-05-26 16:29   ` James Morse
2020-05-26 16:29     ` James Morse
2020-05-26 16:29     ` James Morse
2020-05-27 10:22     ` Marc Zyngier
2020-05-27 10:22       ` Marc Zyngier
2020-05-27 10:22       ` Marc Zyngier
2020-04-22 12:00 ` [PATCH 20/26] KVM: arm64: Move ELR_EL1 to the system register array Marc Zyngier
2020-04-22 12:00   ` Marc Zyngier
2020-04-22 12:00   ` Marc Zyngier
2020-05-26 16:29   ` James Morse
2020-05-26 16:29     ` James Morse
2020-05-26 16:29     ` James Morse
2020-05-27 10:36     ` Marc Zyngier
2020-05-27 10:36       ` Marc Zyngier
2020-05-27 10:36       ` Marc Zyngier
2020-04-22 12:00 ` [PATCH 21/26] KVM: arm64: Move SP_EL1 " Marc Zyngier
2020-04-22 12:00   ` Marc Zyngier
2020-04-22 12:00   ` Marc Zyngier
2020-05-26 16:29   ` James Morse
2020-05-26 16:29     ` James Morse
2020-05-26 16:29     ` James Morse
2020-04-22 12:00 ` [PATCH 22/26] KVM: arm64: Disintegrate SPSR array Marc Zyngier
2020-04-22 12:00   ` Marc Zyngier
2020-04-22 12:00   ` Marc Zyngier
2020-05-26 16:30   ` James Morse
2020-05-26 16:30     ` James Morse
2020-05-26 16:30     ` James Morse
2020-04-22 12:00 ` [PATCH 23/26] KVM: arm64: Move SPSR_EL1 to the system register array Marc Zyngier
2020-04-22 12:00   ` Marc Zyngier
2020-04-22 12:00   ` Marc Zyngier
2020-05-26 16:30   ` James Morse
2020-05-26 16:30     ` James Morse
2020-05-26 16:30     ` James Morse
2020-04-22 12:00 ` [PATCH 24/26] KVM: arm64: timers: Rename kvm_timer_sync_hwstate to kvm_timer_sync_user Marc Zyngier
2020-04-22 12:00   ` Marc Zyngier
2020-04-22 12:00   ` Marc Zyngier
2020-04-22 12:00 ` [PATCH 25/26] KVM: arm64: timers: Move timer registers to the sys_regs file Marc Zyngier
2020-04-22 12:00   ` Marc Zyngier
2020-04-22 12:00   ` Marc Zyngier
2020-04-22 12:00 ` [PATCH 26/26] KVM: arm64: Parametrize exception entry with a target EL Marc Zyngier
2020-04-22 12:00   ` Marc Zyngier
2020-04-22 12:00   ` Marc Zyngier
2020-05-19 10:44   ` Mark Rutland
2020-05-19 10:44     ` Mark Rutland
2020-05-19 10:44     ` Mark Rutland
2020-05-27  9:34     ` Marc Zyngier
2020-05-27  9:34       ` Marc Zyngier
2020-05-27  9:34       ` Marc Zyngier
2020-05-27 14:41       ` Mark Rutland
2020-05-27 14:41         ` Mark Rutland
2020-05-27 14:41         ` Mark Rutland

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20200505172351.GD237572@google.com \
    --to=ascull@google.com \
    --cc=Dave.Martin@arm.com \
    --cc=andre.przywara@arm.com \
    --cc=catalin.marinas@arm.com \
    --cc=gcherian@marvell.com \
    --cc=kvm@vger.kernel.org \
    --cc=kvmarm@lists.cs.columbia.edu \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=maz@kernel.org \
    --cc=prime.zeng@hisilicon.com \
    --cc=will@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.