Re: [PATCH] KVM: arm64: ITS: move ITS registration into first VCPU run

On 03/08/2016 19:56, Auger Eric wrote: > Hi > > On 03/08/2016 19:48, Auger Eric wrote: >> Hi Andre, Christoffer, >> >> On 03/08/2016 19:18, Andre Przywara wrote: >>> Hi, >>> >>> On 03/08/16 18:11, Christoffer Dall wrote: On Wed, Aug 03, 2016 at 03:57:45PM +0100, Andre Przywara wrote: >

Re: [PATCH] KVM: arm64: ITS: move ITS registration into first VCPU run

Hi Andre, [auto build test ERROR on kvmarm/next] [also build test ERROR on next-20160803] [cannot apply to v4.7] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com/0day-ci/linux/commits/Andre-Przywara/KVM-arm64-ITS-move

Re: [PATCH] KVM: arm64: ITS: move ITS registration into first VCPU run

Hi On 03/08/2016 19:48, Auger Eric wrote: > Hi Andre, Christoffer, > > On 03/08/2016 19:18, Andre Przywara wrote: >> Hi, >> >> On 03/08/16 18:11, Christoffer Dall wrote: >>> On Wed, Aug 03, 2016 at 03:57:45PM +0100, Andre Przywara wrote: Currently we register ITS devices upon userland

Re: [PATCH] KVM: arm64: ITS: move ITS registration into first VCPU run

On Wed, Aug 03, 2016 at 07:48:15PM +0200, Auger Eric wrote: > Hi Andre, Christoffer, > > On 03/08/2016 19:18, Andre Przywara wrote: > > Hi, > > > > On 03/08/16 18:11, Christoffer Dall wrote: > >> On Wed, Aug 03, 2016 at 03:57:45PM +0100, Andre Przywara wrote: > >>> Currently we register ITS

Re: [PATCH] KVM: arm64: ITS: move ITS registration into first VCPU run

Hi Andre, Christoffer, On 03/08/2016 19:18, Andre Przywara wrote: > Hi, > > On 03/08/16 18:11, Christoffer Dall wrote: >> On Wed, Aug 03, 2016 at 03:57:45PM +0100, Andre Przywara wrote: >>> Currently we register ITS devices upon userland issuing the CTRL_INIT >>> ioctl to mark initialization of

Re: [PATCH] KVM: arm64: ITS: move ITS registration into first VCPU run

On Wed, Aug 03, 2016 at 06:18:48PM +0100, Andre Przywara wrote: > Hi, > > On 03/08/16 18:11, Christoffer Dall wrote: > > On Wed, Aug 03, 2016 at 03:57:45PM +0100, Andre Przywara wrote: > >> Currently we register ITS devices upon userland issuing the CTRL_INIT > >> ioctl to mark initialization of

Re: [PATCH v2] KVM: arm64: ITS: return 1 on successful MSI injection

On Tue, Aug 02, 2016 at 01:56:05PM +0100, Andre Przywara wrote: > According to the KVM API documentation a successful MSI injection > should return a value > 0 on success. > Return possible errors in vgic_its_trigger_msi() and report a > successful injection back to userland, while also reporting

Re: [PATCH] KVM: arm64: ITS: move ITS registration into first VCPU run

Hi, On 03/08/16 18:11, Christoffer Dall wrote: > On Wed, Aug 03, 2016 at 03:57:45PM +0100, Andre Przywara wrote: >> Currently we register ITS devices upon userland issuing the CTRL_INIT >> ioctl to mark initialization of the ITS as done. >> This deviates from the initialization sequence of the

Re: [PATCH] KVM: arm64: ITS: move ITS registration into first VCPU run

On Wed, Aug 03, 2016 at 03:57:45PM +0100, Andre Przywara wrote: > Currently we register ITS devices upon userland issuing the CTRL_INIT > ioctl to mark initialization of the ITS as done. > This deviates from the initialization sequence of the existing GIC > devices and does not play well with the

Re: [PATCH] KVM: arm64: ITS: move ITS registration into first VCPU run

On Wed, Aug 03, 2016 at 03:57:45PM +0100, Andre Przywara wrote: > Currently we register ITS devices upon userland issuing the CTRL_INIT > ioctl to mark initialization of the ITS as done. > This deviates from the initialization sequence of the existing GIC > devices and does not play well with the

[PATCH 3/3] KVM: arm64: vgic-its: Make updates to propbaser/pendbaser atomic

There are two problems with the current implementation of the MMIO handlers for the propbaser and pendbaser: First, the write to the value itself is not guaranteed to be an atomic 64-bit write so two concurrent writes to the structure field could be intermixed. Second, because we do a

[PATCH v2 1/3] KVM: arm64: vgic-its: Handle errors from vgic_add_lpi

During low memory conditions, we could be dereferencing a NULL pointer when vgic_add_lpi fails to allocate memory. Consider for example this call sequence: vgic_its_cmd_handle_mapi itte->irq = vgic_add_lpi(kvm, lpi_nr); update_lpi_config(kvm, itte->irq, NULL); ret

[PATCH 0/3] KVM: arm64: vgic-its fixes

Here are three small fixes resulting from looking at the pull request of kvmarm/next into kvm/next. They basically deal with corner cases in the reference count handling and atomicity issues. Christoffer Dall (3): KVM: arm64: vgic-its: Handle errors from vgic_add_lpi KVM: arm64: vgic-its:

[PATCH 2/3] KVM: arm64: vgic-its: Plug race in vgic_put_irq

Right now the following sequence of events can happen: 1. Thread X calls vgic_put_irq 2. Thread Y calls vgic_add_lpi 3. Thread Y gets lpi_list_lock 4. Thread X drops the ref count to 0 and blocks on lpi_list_lock 5. Thread Y finds the irq via the lpi_list_lock, raises the ref count

[PATCH] KVM: arm64: ITS: move ITS registration into first VCPU run

Currently we register ITS devices upon userland issuing the CTRL_INIT ioctl to mark initialization of the ITS as done. This deviates from the initialization sequence of the existing GIC devices and does not play well with the way QEMU handles things. To be more in line with what we are used to,

Re: [RFC PATCH v1 2/4] arm/arm64: vgic-new: Add distributor and redistributor access

On Wed, Aug 03, 2016 at 02:03:39PM +0530, Vijay Kilari wrote: > On Tue, Aug 2, 2016 at 8:13 PM, Christoffer Dall > wrote: > > On Wed, Jul 20, 2016 at 06:32:26PM +0530, vijay.kil...@gmail.com wrote: > >> From: Vijaya Kumar K > >> > >> VGICv3

Re: [RFC PATCH v1 2/4] arm/arm64: vgic-new: Add distributor and redistributor access

On Tue, Aug 2, 2016 at 8:13 PM, Christoffer Dall wrote: > On Wed, Jul 20, 2016 at 06:32:26PM +0530, vijay.kil...@gmail.com wrote: >> From: Vijaya Kumar K >> >> VGICv3 Distributor and Redistributor registers are accessed using >>

Re: [PATCH] KVM: arm/arm64: initialize new VGIC even without host GIC

On 2016-08-02 07:34, Andre Przywara wrote: > The new VGIC code is always in the VCPU entry/exit path, even when the > actual GIC hardware initialization found the VGIC unusable (due to > non-aligned base addresses or a missing maintenance interrupt, for > instance). > Since in this case the VGIC