Re: [PATCH v4 18/21] KVM: arm64: Handle RAS SErrors from EL1 on guest exit

On Thu, Oct 19, 2017 at 03:58:04PM +0100, James Morse wrote: > We expect to have firmware-first handling of RAS SErrors, with errors > notified via an APEI method. For systems without firmware-first, add > some minimal handling to KVM. > > There are two ways KVM can take an SError due to a guest,

Re: [PATCH v4 15/21] KVM: arm64: Set an impdef ESR for Virtual-SError using VSESR_EL2.

On Mon, Oct 30, 2017 at 03:44:17PM +, James Morse wrote: > Hi Christoffer, > > On 30/10/17 10:51, Christoffer Dall wrote: > > On Mon, Oct 30, 2017 at 08:59:51AM +0100, Christoffer Dall wrote: > >> On Thu, Oct 19, 2017 at 03:58:01PM +0100, James Morse wrote: > >>> Prior to v8.2's RAS

Re: [PATCH v4 17/21] KVM: arm64: Save ESR_EL2 on guest SError

On Tue, Oct 31 2017 at 4:26:01 am GMT, Marc Zyngier wrote: > On Thu, Oct 19 2017 at 4:58:03 pm BST, James Morse > wrote: >> When we exit a guest due to an SError the vcpu fault info isn't updated >> with the ESR. Today this is only done for traps.

Re: [PATCH v4 16/21] KVM: arm64: Save/Restore guest DISR_EL1

On Thu, Oct 19, 2017 at 03:58:02PM +0100, James Morse wrote: > If we deliver a virtual SError to the guest, the guest may defer it > with an ESB instruction. The guest reads the deferred value via DISR_EL1, > but the guests view of DISR_EL1 is re-mapped to VDISR_EL2 when HCR_EL2.AMO > is set. > >

Re: [PATCH v4 16/21] KVM: arm64: Save/Restore guest DISR_EL1

On Thu, Oct 19 2017 at 4:58:02 pm BST, James Morse wrote: > If we deliver a virtual SError to the guest, the guest may defer it > with an ESB instruction. The guest reads the deferred value via DISR_EL1, > but the guests view of DISR_EL1 is re-mapped to VDISR_EL2 when

Re: [PATCH v4 17/21] KVM: arm64: Save ESR_EL2 on guest SError

On Thu, Oct 19 2017 at 4:58:03 pm BST, James Morse wrote: > When we exit a guest due to an SError the vcpu fault info isn't updated > with the ESR. Today this is only done for traps. > > The v8.2 RAS Extensions define ISS values for SError. Update the vcpu's > fault_info

Re: [PATCH v4 20/28] arm64/sve: Add prctl controls for userspace vector length management

On Mon, Oct 30, 2017 at 04:12:13PM +, Alex Bennée wrote: > > Dave Martin writes: > > > On Fri, Oct 27, 2017 at 06:52:50PM +0100, Alex Bennée wrote: > >> > >> Dave Martin writes: > >> > >> > This patch adds two arm64-specific prctls, to permit

Re: [PATCH v4 20/28] arm64/sve: Add prctl controls for userspace vector length management

Dave Martin writes: > On Fri, Oct 27, 2017 at 06:52:50PM +0100, Alex Bennée wrote: >> >> Dave Martin writes: >> >> > This patch adds two arm64-specific prctls, to permit userspace to >> > control its vector length: >> > >> > * PR_SVE_SET_VL: set the

[PATCH v4 14/13] firmware: arm_sdei: Move cpuhotplug registration later

Will points out the sdei_probe() code may be pre-empted to bring a CPU online. If this happens between registering the cpu-hotplug callbacks and the okay-we're-ready cross call, the new CPU may be left unmasked even if we failed for some other reason. Move the cpuhotplug callback registration

Re: [PATCH v4 15/21] KVM: arm64: Set an impdef ESR for Virtual-SError using VSESR_EL2.

Hi Christoffer, On 30/10/17 10:51, Christoffer Dall wrote: > On Mon, Oct 30, 2017 at 08:59:51AM +0100, Christoffer Dall wrote: >> On Thu, Oct 19, 2017 at 03:58:01PM +0100, James Morse wrote: >>> Prior to v8.2's RAS Extensions, the HCR_EL2.VSE 'virtual SError' feature >>> generated an SError with

Re: [PATCH v4 15/21] KVM: arm64: Set an impdef ESR for Virtual-SError using VSESR_EL2.

On Mon, Oct 30, 2017 at 08:59:51AM +0100, Christoffer Dall wrote: > On Thu, Oct 19, 2017 at 03:58:01PM +0100, James Morse wrote: > > Prior to v8.2's RAS Extensions, the HCR_EL2.VSE 'virtual SError' feature > > generated an SError with an implementation defined ESR_EL1.ISS, because we > > had no

Re: [PATCH v4 15/21] KVM: arm64: Set an impdef ESR for Virtual-SError using VSESR_EL2.

On Thu, Oct 19, 2017 at 03:58:01PM +0100, James Morse wrote: > Prior to v8.2's RAS Extensions, the HCR_EL2.VSE 'virtual SError' feature > generated an SError with an implementation defined ESR_EL1.ISS, because we > had no mechanism to specify the ESR value. > > On Juno this generates an all-zero

Re: [PATCH v4 09/21] KVM: arm/arm64: mask/unmask daif around VHE guests

On Thu, Oct 19, 2017 at 03:57:55PM +0100, James Morse wrote: > Non-VHE systems take an exception to EL2 in order to world-switch into the > guest. When returning from the guest KVM implicitly restores the DAIF > flags when it returns to the kernel at EL1. > > With VHE none of this exception-level

Re: [PATCH] KVM: arm/arm64: Unify 32bit fault injection

On Sun, Oct 29, 2017 at 02:18:09AM +, Marc Zyngier wrote: > Both arm and arm64 implementations are capable of injecting > fauls, and yet have completely divergent implementations, faults > leading to different bugs and reduced maintainability. > > Let's get elect the arm64 version as the

Re: [PATCH v5 24/26] KVM: arm/arm64: GICv4: Prevent userspace from changing doorbell affinity

On Fri, Oct 27, 2017 at 03:28:53PM +0100, Marc Zyngier wrote: > We so far allocate the doorbell interrupts without taking any > special measure regarding the affinity of these interrupts. We > simply move them around as required when the vcpu gets scheduled > on a different CPU. > > But that's

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

On Fri, Oct 27, 2017 at 02:56:10PM +0100, Marc Zyngier wrote: > On Thu, Oct 26 2017 at 5:28:28 pm BST, Christoffer Dall > wrote: > > On Fri, Oct 06, 2017 at 04:33:58PM +0100, Marc Zyngier wrote: > >> The GICv4 architecture doesn't make it easy for save/restore to > >> work, as

Re: [PATCH v5 02/26] KVM: arm/arm64: register irq bypass consumer on ARM/ARM64

On Fri, Oct 27, 2017 at 03:28:31PM +0100, Marc Zyngier wrote: > From: Eric Auger > > This patch selects IRQ_BYPASS_MANAGER and HAVE_KVM_IRQ_BYPASS > configs for ARM/ARM64. > > kvm_arch_has_irq_bypass() now is implemented and returns true. > As a consequence the irq bypass

Re: [PATCH v5 01/26] irqchip/gic-v3-its: Setup VLPI properties at map time

On Fri, Oct 27, 2017 at 03:28:30PM +0100, Marc Zyngier wrote: > So far, we require the hypervisor to update the VLPI properties > once the the VLPI mapping has been established. While this > makes it easy for the ITS driver, it creates a window where > an incoming interrupt can be delivered with

Re: [PATCH v6 0/9] vITS Migration fixes and reset

Hi Eric, On Thu, Oct 26, 2017 at 05:23:02PM +0200, Eric Auger wrote: > This series fixes various bugs observed when saving/restoring the > ITS state before the guest writes the ITS registers (on first boot or > after reset/reboot). > > This is a follow up of Wanghaibin's series [1] plus

Re: [PATCH v6 9/9] KVM: arm/arm64: vgic-its: Implement KVM_DEV_ARM_ITS_CTRL_RESET

On Thu, Oct 26, 2017 at 05:23:11PM +0200, Eric Auger wrote: > On reset we clear the valid bits of GITS_CBASER and GITS_BASER. > We also clear command queue registers and free the cache (device, > collection, and lpi lists). > > As we need to take the same locks as save/restore functions, we >

Re: [PATCH v6 8/9] KVM: arm/arm64: Document KVM_DEV_ARM_ITS_CTRL_RESET

On Thu, Oct 26, 2017 at 05:23:10PM +0200, Eric Auger wrote: > At the moment, the in-kernel emulated ITS is not properly reset. > On guest restart/reset some registers keep their old values and > internal structures like device, ITE, and collection lists are not > freed. > > This may lead to

Re: [PATCH v6 7/9] KVM: arm/arm64: vgic-its: Free caches when GITS_BASER Valid bit is cleared

On Mon, Oct 30, 2017 at 03:19:54AM +, Marc Zyngier wrote: > On Thu, Oct 26 2017 at 6:23:09 pm BST, Eric Auger > wrote: > > When the GITS_BASER.Valid gets cleared, the data structures in > > guest RAM are not valid anymore. The device, collection > > and LPI lists