Re: [PATCH v4 01/40] KVM: arm/arm64: Avoid vcpu_load for other vcpu ioctls than KVM_RUN

On Thu, 15 Feb 2018 21:02:53 +, Christoffer Dall wrote: > > Calling vcpu_load() registers preempt notifiers for this vcpu and calls > kvm_arch_vcpu_load(). The latter will soon be doing a lot of heavy > lifting on arm/arm64 and will try to do things such as enabling the > virtual timer and

Re: [PATCH v4 25/40] KVM: arm64: Introduce framework for accessing deferred sysregs

On Thu, 15 Feb 2018 21:03:17 +, Christoffer Dall wrote: > > We are about to defer saving and restoring some groups of system > registers to vcpu_put and vcpu_load on supported systems. This means > that we need some infrastructure to access system registes which > supports either accessing

Re: [PATCH v4 24/40] KVM: arm64: Rewrite system register accessors to read/write functions

On Thu, 15 Feb 2018 21:03:16 +, Christoffer Dall wrote: > > From: Christoffer Dall > > Currently we access the system registers array via the vcpu_sys_reg() > macro. However, we are about to change the behavior to some times > modify the register file directly, so

Re: [PATCH v2] arm64: Add support for new control bits CTR_EL0.DIC and CTR_EL0.IDC

On Wed, Feb 21, 2018 at 07:10:34AM -0600, Shanker Donthineni wrote: > On 02/21/2018 05:12 AM, Catalin Marinas wrote: > > However, my worry is that in an implementation with DIC set, we also > > skip the DSB/ISB sequence in the invalidate_icache_by_line macro. For > > example, in an implementation

Re: [PATCH v4 26/40] KVM: arm/arm64: Prepare to handle deferred save/restore of SPSR_EL1

On Thu, 15 Feb 2018 21:03:18 +, Christoffer Dall wrote: > > SPSR_EL1 is not used by a VHE host kernel and can be deferred, but we > need to rework the accesses to this register to access the latest value > depending on whether or not guest system registers are loaded on the CPU > or only

Re: [PATCH v3] arm64: Add support for new control bits CTR_EL0.DIC and CTR_EL0.IDC

On Wed, Feb 21, 2018 at 07:49:06AM -0600, Shanker Donthineni wrote: > The DCache clean & ICache invalidation requirements for instructions > to be data coherence are discoverable through new fields in CTR_EL0. > The following two control bits DIC and IDC were defined for this > purpose. No need to

[PATCH v3] arm64: Add support for new control bits CTR_EL0.DIC and CTR_EL0.IDC

The DCache clean & ICache invalidation requirements for instructions to be data coherence are discoverable through new fields in CTR_EL0. The following two control bits DIC and IDC were defined for this purpose. No need to perform point of unification cache maintenance operations from software on

Re: [PATCH v4 27/40] KVM: arm64: Prepare to handle deferred save/restore of ELR_EL1

On Thu, 15 Feb 2018 21:03:19 +, Christoffer Dall wrote: > > ELR_EL1 is not used by a VHE host kernel and can be deferred, but we > need to rework the accesses to this register to access the latest value > depending on whether or not guest system registers are loaded on the CPU > or only

Re: [PATCH 3/4] iommu/virtio: Add event queue

Hi Jean-Philippe, I love your patch! Yet something to improve: [auto build test ERROR on linus/master] [also build test ERROR on v4.16-rc2 next-20180221] [cannot apply to iommu/next] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url

Re: [PATCH v3] arm64: Add support for new control bits CTR_EL0.DIC and CTR_EL0.IDC

Hi Mark, On 02/21/2018 09:09 AM, Mark Rutland wrote: > On Wed, Feb 21, 2018 at 07:49:06AM -0600, Shanker Donthineni wrote: >> The DCache clean & ICache invalidation requirements for instructions >> to be data coherence are discoverable through new fields in CTR_EL0. >> The following two control

Re: [PATCH v4 29/40] KVM: arm64: Prepare to handle deferred save/restore of 32-bit registers

On Thu, 15 Feb 2018 21:03:21 +, Christoffer Dall wrote: > > 32-bit registers are not used by a 64-bit host kernel and can be > deferred, but we need to rework the accesses to this register to access > the latest value depending on whether or not guest system registers are > loaded on the CPU

Re: [PATCH v4 28/40] KVM: arm64: Defer saving/restoring 64-bit sysregs to vcpu load/put on VHE

On Thu, 15 Feb 2018 21:03:20 +, Christoffer Dall wrote: > > Some system registers do not affect the host kernel's execution and can > therefore be loaded when we are about to run a VCPU and we don't have to > restore the host state to the hardware before the time when we are > actually about

Re: [PATCH v3] arm64: Add support for new control bits CTR_EL0.DIC and CTR_EL0.IDC

On 21/02/18 16:14, Shanker Donthineni wrote: [...] @@ -1100,6 +1114,20 @@ static int cpu_copy_el2regs(void *__unused) .enable = cpu_clear_disr, }, #endif /* CONFIG_ARM64_RAS_EXTN */ +#ifdef CONFIG_ARM64_SKIP_CACHE_POU + { + .desc = "DCache clean to

Re: [PATCH v4 30/40] KVM: arm64: Defer saving/restoring 32-bit sysregs to vcpu load/put

On Thu, 15 Feb 2018 21:03:22 +, Christoffer Dall wrote: > > When running a 32-bit VM (EL1 in AArch32), the AArch32 system registers > can be deferred to vcpu load/put on VHE systems because neither > the host kernel nor host userspace uses these registers. > > Note that we can not defer

Re: [PATCH v4 08/40] KVM: arm/arm64: Introduce vcpu_el1_is_32bit

On Thu, 15 Feb 2018 21:03:00 +, Christoffer Dall wrote: > > We have numerous checks around that checks if the HCR_EL2 has the RW bit > set to figure out if we're running an AArch64 or AArch32 VM. In some > cases, directly checking the RW bit (given its unintuitive name), is a > bit

Re: [PATCH v4 17/40] KVM: arm64: Move userspace system registers into separate function

On Thu, 15 Feb 2018 21:03:09 +, Christoffer Dall wrote: > > There's a semantic difference between the EL1 registers that control > operation of a kernel running in EL1 and EL1 registers that only control > userspace execution in EL0. Since we can defer saving/restoring the > latter, move

Re: [PATCH v2] arm64: Add support for new control bits CTR_EL0.DIC and CTR_EL0.IDC

Hi Catalin, On 02/21/2018 05:12 AM, Catalin Marinas wrote: > On Mon, Feb 19, 2018 at 08:59:06PM -0600, Shanker Donthineni wrote: >> diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig >> index f55fe5b..4061210 100644 >> --- a/arch/arm64/Kconfig >> +++ b/arch/arm64/Kconfig >> @@ -1095,6 +1095,27

Re: [PATCH v4 03/40] KVM: arm64: Avoid storing the vcpu pointer on the stack

On Thu, 15 Feb 2018 21:02:55 +, Christoffer Dall wrote: > > We already have the percpu area for the host cpu state, which points to > the VCPU, so there's no need to store the VCPU pointer on the stack on > every context switch. We can be a little more clever and just use > tpidr_el2 for the

Re: [PATCH v4 02/40] KVM: arm/arm64: Move vcpu_load call after kvm_vcpu_first_run_init

On Thu, 15 Feb 2018 21:02:54 +, Christoffer Dall wrote: > > Moving the call to vcpu_load() in kvm_arch_vcpu_ioctl_run() to after > we've called kvm_vcpu_first_run_init() simplifies some of the vgic and > there is also no need to do vcpu_load() for things such as handling the > immediate_exit

Re: [PATCH v2] arm64: Add support for new control bits CTR_EL0.DIC and CTR_EL0.IDC

On Mon, Feb 19, 2018 at 08:59:06PM -0600, Shanker Donthineni wrote: > diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig > index f55fe5b..4061210 100644 > --- a/arch/arm64/Kconfig > +++ b/arch/arm64/Kconfig > @@ -1095,6 +1095,27 @@ config ARM64_RAS_EXTN > and access the new registers if

Re: [PATCH v4 01/40] KVM: arm/arm64: Avoid vcpu_load for other vcpu ioctls than KVM_RUN

On Thu, Feb 15, 2018 at 10:02:53PM +0100, Christoffer Dall wrote: > Calling vcpu_load() registers preempt notifiers for this vcpu and calls > kvm_arch_vcpu_load(). The latter will soon be doing a lot of heavy > lifting on arm/arm64 and will try to do things such as enabling the > virtual timer

Re: [PATCH v4 12/40] KVM: arm64: Factor out fault info population and gic workarounds

On Thu, Feb 15, 2018 at 10:03:04PM +0100, Christoffer Dall wrote: > The current world-switch function has functionality to detect a number > of cases where we need to fixup some part of the exit condition and > possibly run the guest again, before having restored the host state. > > This includes

Re: [PATCH v4 13/40] KVM: arm64: Introduce VHE-specific kvm_vcpu_run

On Thu, Feb 15, 2018 at 10:03:05PM +0100, Christoffer Dall wrote: > So far this is mostly (see below) a copy of the legacy non-VHE switch > function, but we will start reworking these functions in separate > directions to work on VHE and non-VHE in the most optimal way in later > patches. > > The

Re: [PATCH v4 18/40] KVM: arm64: Rewrite sysreg alternatives to static keys

On Thu, Feb 15, 2018 at 10:03:10PM +0100, Christoffer Dall wrote: > As we are about to move calls around in the sysreg save/restore logic, > let's first rewrite the alternative function callers, because it is > going to make the next patches much easier to read. > > Acked-by: Marc Zyngier

Re: [PATCH v4 22/40] KVM: arm64: Don't save the host ELR_EL2 and SPSR_EL2 on VHE systems

On Thu, Feb 15, 2018 at 10:03:14PM +0100, Christoffer Dall wrote: > On non-VHE systems we need to save the ELR_EL2 and SPSR_EL2 so that we can > return to the host in EL1 in the same state and location where we issued a > hypercall to EL2, but on VHE ELR_EL2 and SPSR_EL2 are not useful because we

Re: [PATCH v4 10/40] KVM: arm64: Slightly improve debug save/restore functions

On 21/02/18 17:39, Andrew Jones wrote: > On Thu, Feb 15, 2018 at 10:03:02PM +0100, Christoffer Dall wrote: >> The debug save/restore functions can be improved by using the has_vhe() >> static key instead of the instruction alternative. Using the static key >> uses the same paradigm as we're going

Re: [PATCH v4 32/40] KVM: arm64: Directly call VHE and non-VHE FPSIMD enabled functions

On Thu, 15 Feb 2018 21:03:24 +, Christoffer Dall wrote: > > There is no longer a need for an alternative to choose the right > function to tell us whether or not FPSIMD was enabled for the VM, > because we can simply cann the appropriate functions directly fromwithin from within > the _vhe

Re: [PATCH v4 09/40] KVM: arm64: Move debug dirty flag calculation out of world switch

On Thu, Feb 15, 2018 at 10:03:01PM +0100, Christoffer Dall wrote: > There is no need to figure out inside the world-switch if we should > save/restore the debug registers or not, we might as well do that in the > higher level debug setup code, making it easier to optimize down the > line. > >

Re: [PATCH v4 11/40] KVM: arm64: Improve debug register save/restore flow

On Thu, Feb 15, 2018 at 10:03:03PM +0100, Christoffer Dall wrote: > Instead of having multiple calls from the world switch path to the debug > logic, each figuring out if the dirty bit is set and if we should > save/restore the debug registers, let's just provide two hooks to the > debug

Re: [PATCH v4 20/40] KVM: arm/arm64: Remove leftover comment from kvm_vcpu_run_vhe

On Thu, Feb 15, 2018 at 10:03:12PM +0100, Christoffer Dall wrote: > The comment only applied to SPE on non-VHE systems, so we simply remove > it. > > Suggested-by: Andrew Jones > Acked-by: Marc Zyngier > Signed-off-by: Christoffer Dall

Re: [PATCH v4 03/40] KVM: arm64: Avoid storing the vcpu pointer on the stack

On Thu, Feb 15, 2018 at 10:02:55PM +0100, Christoffer Dall wrote: > We already have the percpu area for the host cpu state, which points to > the VCPU, so there's no need to store the VCPU pointer on the stack on > every context switch. We can be a little more clever and just use > tpidr_el2 for

Re: [PATCH v4 08/40] KVM: arm/arm64: Introduce vcpu_el1_is_32bit

On Thu, Feb 15, 2018 at 10:03:00PM +0100, Christoffer Dall wrote: > We have numerous checks around that checks if the HCR_EL2 has the RW bit > set to figure out if we're running an AArch64 or AArch32 VM. In some > cases, directly checking the RW bit (given its unintuitive name), is a > bit

Re: [PATCH v4 16/40] KVM: arm64: Remove noop calls to timer save/restore from VHE switch

On Thu, Feb 15, 2018 at 10:03:08PM +0100, Christoffer Dall wrote: > The VHE switch function calls __timer_enable_traps and > __timer_disable_traps which don't do anything on VHE systems. > Therefore, simply remove these calls from the VHE switch function and > make the functions non-conditional as

Re: [PATCH v4 31/40] KVM: arm64: Move common VHE/non-VHE trap config in separate functions

On Thu, 15 Feb 2018 21:03:23 +, Christoffer Dall wrote: > > As we are about to be more lazy with some of the trap configuration > register read/writes for VHE systems, move the logic that is currently > shared between VHE and non-VHE into a separate function which can be > called from either

Re: [PATCH v4 33/40] KVM: arm64: Configure c15, PMU, and debug register traps on cpu load/put for VHE

On Thu, 15 Feb 2018 21:03:25 +, Christoffer Dall wrote: > > We do not have to change the c15 trap setting on each switch to/from the > guest on VHE systems, because this setting only affects EL0. Did you mean EL1 instead? > > The PMU and debug trap configuration can also be done on vcpu

Re: [PATCH 1/4] iommu: Add virtio-iommu driver

Hi Jean-Philippe, I love your patch! Yet something to improve: [auto build test ERROR on linus/master] [also build test ERROR on v4.16-rc2 next-20180221] [cannot apply to iommu/next] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url

Re: [PATCH v4 13/40] KVM: arm64: Introduce VHE-specific kvm_vcpu_run

On Wed, Feb 21, 2018 at 06:43:00PM +0100, Andrew Jones wrote: > On Thu, Feb 15, 2018 at 10:03:05PM +0100, Christoffer Dall wrote: > > So far this is mostly (see below) a copy of the legacy non-VHE switch > > function, but we will start reworking these functions in separate > > directions to work

Re: [PATCH 1/4] iommu: Add virtio-iommu driver

Hi Jean-Philippe, I love your patch! Yet something to improve: [auto build test ERROR on linus/master] [also build test ERROR on v4.16-rc2 next-20180221] [cannot apply to iommu/next] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url

Re: [PATCH v4 34/40] KVM: arm64: Cleanup __activate_traps and __deactive_traps for VHE and non-VHE

On Thu, 15 Feb 2018 21:03:26 +, Christoffer Dall wrote: > > To make the code more readable and to avoid the overhead of a function > call, let's get rid of a pair of the alternative function selectors and > explicitly call the VHE and non-VHE functions using the has_vhe() static > key based