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

2016-08-08 Thread Andre Przywara
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 the case where the MSI could not be delivered due to the guest not having

Re: [PATCH] kvmtool: ARM: madvise mergeable and hugepage separately

2016-08-08 Thread Andre Przywara
Hi, On 08/08/16 08:01, Stefan Agner wrote: > The madvise behavior is not a bit field and hence can not be or'ed. > Also madvise_behavior_valid checks the flag using a case statement > hence only one behavior is supposed to be supplied. Call madvise > twice, once for MERGEABLE and once for HUGEPAGE

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

2016-08-08 Thread Andre Przywara
Currently we register an ITS device upon userland issuing the CTLR_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, r

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

2016-08-08 Thread Andre Przywara
Hi, On 03/08/16 17:13, Christoffer Dall wrote: > 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

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

2016-08-08 Thread Andre Przywara
Hi, On 03/08/16 17:13, Christoffer Dall wrote: > 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 f

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

2016-08-08 Thread Andre Przywara
Hi, On 03/08/16 17:13, Christoffer Dall wrote: > 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); Ouch!

[PATCH] kvmtool: ARM: madvise mergeable and hugepage separately

2016-08-08 Thread Stefan Agner
The madvise behavior is not a bit field and hence can not be or'ed. Also madvise_behavior_valid checks the flag using a case statement hence only one behavior is supposed to be supplied. Call madvise twice, once for MERGEABLE and once for HUGEPAGE. Signed-off-by: Stefan Agner --- arm/kvm.c | 5 +