Re: [3/3] arm64: Add software workaround for Falkor erratum 1041

On Thu, 2 Nov 2017, Shanker Donthineni wrote: The ARM architecture defines the memory locations that are permitted to be accessed as the result of a speculative instruction fetch from an exception level for which all stages of translation are disabled. Specifically, the core is permitted to

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

On Thu, Oct 12, 2017 at 12:41:25PM +0200, 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 these registers don't contain anything > important on

Re: [PATCH v5 12/30] arm64/sve: Low-level CPU setup

Dave Martin writes: > To enable the kernel to use SVE, SVE traps from EL1 to EL2 must be > disabled. To take maximum advantage of the hardware, the full > available vector length also needs to be enabled for EL1 by > programming ZCR_EL2.LEN. (The kernel will program

Re: [PATCH v5 11/30] arm64/sve: Signal frame and context structure definition

Dave Martin writes: > This patch defines the representation that will be used for the SVE > register state in the signal frame, and implements support for > saving and restoring the SVE registers around signals. > > The same layout will also be used for the in-kernel task

Re: [PATCH v5 15/30] arm64/sve: Signal handling support

On Tue, Nov 07, 2017 at 01:22:33PM +, Alex Bennée wrote: > > Dave Martin writes: > > > This patch implements support for saving and restoring the SVE > > registers around signals. > > > > A fixed-size header struct sve_context is always included in the > > signal frame

[PATCH v4 15/13] firmware: arm_sdei: be more robust against cpu-hotplug

dpm_suspend() calls the freeze/thaw callbacks for hibernate before disable_non_bootcpus() takes down secondaries. This leads to a fun race where the freeze/thaw callbacks reset the SDEI interface (as we may be restoring a kernel with a different layout due to KASLR), then the cpu-hotplug

Re: [PATCH v5 26/26] KVM: arm/arm64: GICv4: Theory of operations

On 08/11/17 09:13, Auger Eric wrote: > Hi Marc, > > On 27/10/2017 16:28, Marc Zyngier wrote: >> Yet another braindump so I can free some cells... >> >> Acked-by: Christoffer Dall >> Signed-off-by: Marc Zyngier >> --- >>

Re: [PATCH v5 25/26] KVM: arm/arm64: GICv4: Enable VLPI support

On 08/11/17 08:44, Auger Eric wrote: > Hi Marc, > > On 27/10/2017 16:28, Marc Zyngier wrote: >> All it takes is the has_v4 flag to be set in gic_kvm_info >> as well as "kvm-arm.vgic_v4_enable=1" being passed on the >> command line for GICv4 to be enabled in KVM. > > What did you motivate your

Re: [PATCH 15/13] firmware: arm_sdei: move the frozen flag under the spinlock

On 01/11/17 15:59, James Morse wrote: > dpm_suspend() calls the freeze/thaw callbacks for hibernate before > disable_non_bootcpus() takes down secondaries. > > This leads to a fun race where the freeze/thaw callbacks reset the > SDEI interface (as we may be restoring a kernel with a different >

Re: [PATCH v5 16/26] KVM: arm/arm64: GICv4: Propagate property updates to VLPIs

On 07/11/17 21:28, Auger Eric wrote: > Hi Marc, > > On 27/10/2017 16:28, Marc Zyngier wrote: >> Upon updating a property, we propagate it all the way to the physical >> ITS, and ask for an INV command to be executed there. >> >> Acked-by: Christoffer Dall >> Signed-off-by: Marc

Re: [PATCH v5 11/26] KVM: arm/arm64: GICv4: Handle INT command applied to a VLPI

Hi Marc, On 08/11/2017 12:40, Marc Zyngier wrote: > On 07/11/17 20:15, Auger Eric wrote: >> Hi Marc, >> >> On 27/10/2017 16:28, Marc Zyngier wrote: >>> If the guest issues an INT command targetting a VLPI, let's >>> call into the irq_set_irqchip_state() helper to make it pending >>> on the

Re: [PATCH v5 13/26] KVM: arm/arm64: GICv4: Propagate affinity changes to the physical ITS

On 07/11/17 21:01, Auger Eric wrote: > Hi Marc, > > On 27/10/2017 16:28, Marc Zyngier wrote: >> When the guest issues an affinity change, we need to tell the physical >> ITS that we're now targetting a new vcpu. This is done by extracting >> the current mapping, updating the target, and

Re: [PATCH v5 12/26] KVM: arm/arm64: GICv4: Unmap VLPI when freeing an LPI

On 07/11/17 20:28, Auger Eric wrote: > Hi Marc, > > On 27/10/2017 16:28, Marc Zyngier wrote: >> When freeing an LPI (on a DISCARD command, for example), we need >> to unmap the VLPI down to the physical ITS level. >> >> Acked-by: Christoffer Dall >> Signed-off-by: Marc Zyngier

Re: [PATCH v5 01/30] regset: Add support for dynamically sized regsets

Dave Martin writes: > On Wed, Nov 01, 2017 at 11:42:29AM +, Catalin Marinas wrote: >> On Tue, Oct 31, 2017 at 03:50:53PM +, Dave P Martin wrote: >> > Currently the regset API doesn't allow for the possibility that >> > regsets (or at least, the amount of meaningful

Re: [PATCH v5 11/26] KVM: arm/arm64: GICv4: Handle INT command applied to a VLPI

On 07/11/17 20:15, Auger Eric wrote: > Hi Marc, > > On 27/10/2017 16:28, Marc Zyngier wrote: >> If the guest issues an INT command targetting a VLPI, let's >> call into the irq_set_irqchip_state() helper to make it pending >> on the physical side. >> >> This works just as well if userspace

Re: [PATCH v5 10/26] KVM: arm/arm64: GICv4: Wire mapping/unmapping of VLPIs in VFIO irq bypass

On 07/11/17 15:59, Auger Eric wrote: > Hi, > > On 07/11/2017 15:42, Marc Zyngier wrote: >> Hi Eric, >> >> On 07/11/17 13:06, Auger Eric wrote: >>> Hi Marc, >>> >>> On 27/10/2017 16:28, Marc Zyngier wrote: Let's use the irq bypass mechanism introduced for platform device interrupts >>>

Re: [PATCH 20/37] KVM: arm64: Unify non-VHE host/guest sysreg save and restore functions

On Thu, Oct 12, 2017 at 12:41:24PM +0200, Christoffer Dall wrote: > There is no need to have multiple identical functions with different > names for saving host and guest state. When saving and restoring state > for the host and guest, the state is the same for both contexts, and > that's why we

Re: [PATCH 19/37] KVM: arm64: Introduce separate VHE/non-VHE sysreg save/restore functions

On Thu, Oct 12, 2017 at 12:41:23PM +0200, Christoffer Dall wrote: > As we are about to handle system registers quite differently between VHE > and non-VHE systems. In preparation for that, we need to split some of > the handling functions between VHE and non-VHE functionality. > > For now, we

Re: [PATCH v5 23/26] KVM: arm/arm64: GICv4: Prevent a VM using GICv4 from being saved

Hi, On 07/11/2017 23:24, Auger Eric wrote: > Hi > > On 07/11/2017 17:34, Marc Zyngier wrote: >> On 07/11/17 16:12, Auger Eric wrote: >>> Hi Marc, >>> >>> On 07/11/2017 16:38, Marc Zyngier wrote: On 07/11/17 15:24, Auger Eric wrote: > Hi Marc, > > Hi Marc, > On 27/10/2017

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

On Thu, Oct 12, 2017 at 12:41:21PM +0200, 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 v5 26/26] KVM: arm/arm64: GICv4: Theory of operations

Hi Marc, On 27/10/2017 16:28, Marc Zyngier wrote: > Yet another braindump so I can free some cells... > > Acked-by: Christoffer Dall > Signed-off-by: Marc Zyngier > --- > virt/kvm/arm/vgic/vgic-v4.c | 67 >

Re: [PATCH v5 22/26] KVM: arm/arm64: GICv4: Enable virtual cpuif if VLPIs can be delivered

Hi, On 27/10/2017 16:28, Marc Zyngier wrote: > In order for VLPIs to be delivered to the guest, we must make > sure that the virtual cpuif is always enabled, irrespective of the > presence of virtual interrupt in the LRs. > > Acked-by: Christoffer Dall > Signed-off-by: Marc

Re: [PATCH v5 25/26] KVM: arm/arm64: GICv4: Enable VLPI support

Hi Marc, On 27/10/2017 16:28, Marc Zyngier wrote: > All it takes is the has_v4 flag to be set in gic_kvm_info > as well as "kvm-arm.vgic_v4_enable=1" being passed on the > command line for GICv4 to be enabled in KVM. What did you motivate your choice of having an enable option instead of a