Re: kvm oops vgic_v2_sync_lr_elrsr

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi Riku,

thanks for reporting that.
I found the root cause of it, it is a kernel bug introduced with -rc1,
during refactoring of the GIC code in preparation for GICv3 support.

On 22/09/14 13:00, Riku Voipio wrote:
> Since last week, we have been getting and Ooops when launching kvm on
> mustang. This is with kvm-arm git with testing/mustang branch, but I
> also reproduced it with 3.17-rc6 (as attached on the log).
> 
> PC is at set_bit+0x14/0x30

set_bit is using ldxr, which requires the memory to be naturally
aligned. The bitmap is not, since it is composed of two u32's to make
the code easier to compile on 32-bit.

> LR is at vgic_v2_sync_lr_elrsr+0x20/0x28

This code snippet is only called when using level interrupts. kvmtool
and older QEMU version only use edge triggered interrupts and thus never
call this code.
I don't have a newest QEMU version running yet (due to having fun
cross-compiling the bloody glib), so cannot test here, but obviously it
uses level interrupts somewhere.
EDIT: it does:
http://git.qemu.org/?p=qemu.git;a=commitdiff;h=0be969a2d974971628fc4ed95834d22ecf0fd497

Riku, can you dump the guest's device tree (-dumpdtb on QEMU cmdline) to
confirm that a device uses a level interrupt? They should have a 4 (or
8) in the last of the three numbers in the interrupts property.

I am just about to think about the best fix (__set_bit, reordering
members of the struct).

Christoffer, any suggestions? Prepare for a sprint to get a fix into
before the release. Marc is out of office (Murphy's law).

Regards,
Andre.

> This is with Qemu from git head, with the following command line:
> 
> qemu-system-aarch64 -smp 2 -m 1024 -cpu host -M virt    -kernel
> ./Image     -append 'root=/dev/vda2 rw rootwait mem=1024M
> earlyprintk=pl011,0x9000000 console=ttyAMA0,38400n8'    -netdev
> user,id=user0 -device virtio-net-device,netdev=user0 -nographic
> -enable-kvm
> 
> I tried also with qemu 2.0 frim ubuntu trusty, and was not able to
> reproduce it. It must be some recent changes in qemu that trigger the
> Oops in kernel.

_______________________________________________
kvmarm mailing list
kvmarm@xxxxxxxxxxxxxxxxxxxxx
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm




[Index of Archives]     [Linux KVM]     [Spice Development]     [Libvirt]     [Libvirt Users]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux