linux-toradex.git/virt, branch v3.14.57

kvm: fix zero length mmio searching

2015-10-22T21:39:16+00:00

commit 8f4216c7d28976f7ec1b2bcbfa0a9f787133c45e upstream.

Currently, if we had a zero length mmio eventfd assigned on
KVM_MMIO_BUS. It will never be found by kvm_io_bus_cmp() since it
always compares the kvm_io_range() with the length that guest
wrote. This will cause e.g for vhost, kick will be trapped by qemu
userspace instead of vhost. Fixing this by using zero length if an
iodevice is zero length.

Cc: Gleb Natapov 
Cc: Paolo Bonzini 
Signed-off-by: Jason Wang 
Reviewed-by: Cornelia Huck 
Signed-off-by: Paolo Bonzini 
Signed-off-by: Greg Kroah-Hartman

arm/arm64: KVM: Keep elrsr/aisr in sync with software model

2015-07-10T17:38:01+00:00

commit ae705930fca6322600690df9dc1c7d0516145a93 upstream.

[Note the upstream one of this patch requires applying full GICv3 support
but it's out of the scope of stable kernel. So this patch has a huge
modification for stable kernel comparing to the upstream one.]

There is an interesting bug in the vgic code, which manifests itself
when the KVM run loop has a signal pending or needs a vmid generation
rollover after having disabled interrupts but before actually switching
to the guest.

In this case, we flush the vgic as usual, but we sync back the vgic
state and exit to userspace before entering the guest.  The consequence
is that we will be syncing the list registers back to the software model
using the GICH_ELRSR and GICH_EISR from the last execution of the guest,
potentially overwriting a list register containing an interrupt.

This showed up during migration testing where we would capture a state
where the VM has masked the arch timer but there were no interrupts,
resulting in a hung test.

Cc: Marc Zyngier 
Reported-by: Alex Bennee 
Signed-off-by: Christoffer Dall 
Signed-off-by: Alex Bennée 
Acked-by: Marc Zyngier 
Signed-off-by: Shannon Zhao 
Signed-off-by: Greg Kroah-Hartman

arm/arm64: KVM: Require in-kernel vgic for the arch timers

2015-07-10T17:38:00+00:00

commit 05971120fca43e0357789a14b3386bb56eef2201 upstream.

[Note this patch is a bit different from the original one as the names of
vgic_initialized and kvm_vgic_init are different.]

It is curently possible to run a VM with architected timers support
without creating an in-kernel VGIC, which will result in interrupts from
the virtual timer going nowhere.

To address this issue, move the architected timers initialization to the
time when we run a VCPU for the first time, and then only initialize
(and enable) the architected timers if we have a properly created and
initialized in-kernel VGIC.

When injecting interrupts from the virtual timer to the vgic, the
current setup should ensure that this never calls an on-demand init of
the VGIC, which is the only call path that could return an error from
kvm_vgic_inject_irq(), so capture the return value and raise a warning
if there's an error there.

We also change the kvm_timer_init() function from returning an int to be
a void function, since the function always succeeds.

Reviewed-by: Marc Zyngier 
Signed-off-by: Christoffer Dall 
Signed-off-by: Shannon Zhao 
Signed-off-by: Greg Kroah-Hartman

arm/arm64: KVM: vgic: Fix error code in kvm_vgic_create()

2015-07-04T02:49:06+00:00

commit 6b50f54064a02b77a7b990032b80234fee59bcd6 upstream.

If we detect another vCPU is running we just exit and return 0 as if we
succesfully created the VGIC, but the VGIC wouldn't actual be created.

This shouldn't break in-kernel behavior because the kernel will not
observe the failed the attempt to create the VGIC, but userspace could
be rightfully confused.

Cc: Andre Przywara 
Signed-off-by: Christoffer Dall 
Signed-off-by: Marc Zyngier 
Signed-off-by: Paolo Bonzini 
Signed-off-by: Shannon Zhao 
Signed-off-by: Greg Kroah-Hartman

arm/arm64: KVM: Fix set_clear_sgi_pend_reg offset

2015-07-04T02:49:06+00:00

commit 0fea6d7628ed6e25a9ee1b67edf7c859718d39e8 upstream.

The sgi values calculated in read_set_clear_sgi_pend_reg() and
write_set_clear_sgi_pend_reg() were horribly incorrectly multiplied by 4
with catastrophic results in that subfunctions ended up overwriting
memory not allocated for the expected purpose.

This showed up as bugs in kfree() and the kernel complaining a lot of
you turn on memory debugging.

This addresses: http://marc.info/?l=kvm&m=141164910007868&w=2

Reported-by: Shannon Zhao 
Signed-off-by: Christoffer Dall 
Signed-off-by: Shannon Zhao 
Signed-off-by: Greg Kroah-Hartman

KVM: ARM: vgic: plug irq injection race

2015-07-04T02:49:06+00:00

commit 71afaba4a2e98bb7bdeba5078370ab43d46e67a1 upstream.

[Since we don't backport commit 227844f (arm/arm64: KVM: Rename irq_state
to irq_pending) for linux-3.14.y, here we still use vgic_update_irq_state
instead of vgic_update_irq_pending.]

As it stands, nothing prevents userspace from injecting an interrupt
before the guest's GIC is actually initialized.

This goes unnoticed so far (as everything is pretty much statically
allocated), but ends up exploding in a spectacular way once we switch
to a more dynamic allocation (the GIC data structure isn't there yet).

The fix is to test for the "ready" flag in the VGIC distributor before
trying to inject the interrupt. Note that in order to avoid breaking
userspace, we have to ignore what is essentially an error.

Signed-off-by: Marc Zyngier 
Acked-by: Christoffer Dall 
Signed-off-by: Shannon Zhao 
Signed-off-by: Greg Kroah-Hartman

KVM: vgic: return int instead of bool when checking I/O ranges

2015-06-29T19:25:38+00:00

commit 1fa451bcc67fa921a04c5fac8dbcde7844d54512 upstream.

vgic_ioaddr_overlap claims to return a bool, but in reality it returns
an int. Shut sparse up by fixing the type signature.

Cc: Christoffer Dall 
Cc: Marc Zyngier 
Signed-off-by: Will Deacon 
Signed-off-by: Christoffer Dall 
Signed-off-by: Shannon Zhao 
Signed-off-by: Greg Kroah-Hartman

kvm: arm64: vgic: fix hyp panic with 64k pages on juno platform

2015-05-17T16:53:52+00:00

commit 63afbe7a0ac184ef8485dac4914e87b211b5bfaa upstream.

If the physical address of GICV isn't page-aligned, then we end up
creating a stage-2 mapping of the page containing it, which causes us to
map neighbouring memory locations directly into the guest.

As an example, consider a platform with GICV at physical 0x2c02f000
running a 64k-page host kernel. If qemu maps this into the guest at
0x80010000, then guest physical addresses 0x80010000 - 0x8001efff will
map host physical region 0x2c020000 - 0x2c02efff. Accesses to these
physical regions may cause UNPREDICTABLE behaviour, for example, on the
Juno platform this will cause an SError exception to EL3, which brings
down the entire physical CPU resulting in RCU stalls / HYP panics / host
crashing / wasted weeks of debugging.

SBSA recommends that systems alias the 4k GICV across the bounding 64k
region, in which case GICV physical could be described as 0x2c020000 in
the above scenario.

This patch fixes the problem by failing the vgic probe if the physical
base address or the size of GICV aren't page-aligned. Note that this
generated a warning in dmesg about freeing enabled IRQs, so I had to
move the IRQ enabling later in the probe.

Cc: Christoffer Dall 
Cc: Marc Zyngier 
Cc: Gleb Natapov 
Cc: Paolo Bonzini 
Cc: Joel Schopp 
Cc: Don Dutile 
Acked-by: Peter Maydell 
Acked-by: Joel Schopp 
Acked-by: Marc Zyngier 
Signed-off-by: Will Deacon 
Signed-off-by: Christoffer Dall 
Cc: Shannon Zhao 
Signed-off-by: Greg Kroah-Hartman

KVM: ARM: vgic: Fix the overlap check action about setting the GICD & GICC base address.

2015-05-17T16:53:52+00:00

commit 30c2117085bc4e05d091cee6eba79f069b41a9cd upstream.

Currently below check in vgic_ioaddr_overlap will always succeed,
because the vgic dist base and vgic cpu base are still kept UNDEF
after initialization. The code as follows will be return forever.

	if (IS_VGIC_ADDR_UNDEF(dist) || IS_VGIC_ADDR_UNDEF(cpu))
                return 0;

So, before invoking the vgic_ioaddr_overlap, it needs to set the
corresponding base address firstly.

Signed-off-by: Haibin Wang 
Acked-by: Marc Zyngier 
Signed-off-by: Christoffer Dall 
Cc: Shannon Zhao 
Signed-off-by: Greg Kroah-Hartman

KVM: arm/arm64: vgic: fix GICD_ICFGR register accesses

2015-05-17T16:53:52+00:00

commit f2ae85b2ab3776b9e4e42e5b6fa090f40d396794 upstream.

Since KVM internally represents the ICFGR registers by stuffing two
of them into one word, the offset for accessing the internal
representation and the one for the MMIO based access are different.
So keep the original offset around, but adjust the internal array
offset by one bit.

Reported-by: Haibin Wang 
Signed-off-by: Andre Przywara 
Signed-off-by: Marc Zyngier 
Signed-off-by: Christoffer Dall 
Cc: Shannon Zhao 
Signed-off-by: Greg Kroah-Hartman