[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Bug Report] smmuv3 event 0x10 report when running virtio-blk-pci
From: |
Peter Maydell |
Subject: |
Re: [Bug Report] smmuv3 event 0x10 report when running virtio-blk-pci |
Date: |
Mon, 9 Sep 2024 15:31:11 +0100 |
On Mon, 9 Sept 2024 at 15:22, Zhou Wang via <qemu-devel@nongnu.org> wrote:
>
> Hi All,
>
> When I tested mainline qemu(commit 7b87a25f49), it reports smmuv3 event 0x10
> during kernel booting up.
Does it still do this if you either:
(1) use the v9.1.0 release (commit fd1952d814da)
(2) use "-machine virt-9.1" instead of "-machine virt"
?
My suspicion is that this will have started happening now that
we expose an SMMU with two-stage translation support to the guest
in the "virt" machine type (which we do not if you either
use virt-9.1 or in the v9.1.0 release).
I've cc'd Eric (smmuv3 maintainer) and Mostafa (author of
the two-stage support).
> qemu command which I use is as below:
>
> qemu-system-aarch64 -machine
> virt,kernel_irqchip=on,gic-version=3,iommu=smmuv3 \
> -kernel Image -initrd minifs.cpio.gz \
> -enable-kvm -net none -nographic -m 3G -smp 6 -cpu host \
> -append 'rdinit=init console=ttyAMA0 ealycon=pl0ll,0x90000000 maxcpus=3' \
> -device
> pcie-root-port,port=0x8,chassis=0,id=pci.0,bus=pcie.0,multifunction=on,addr=0x2
> \
> -device pcie-root-port,port=0x9,chassis=1,id=pci.1,bus=pcie.0,addr=0x2.0x1 \
> -device
> virtio-blk-pci,drive=drive0,id=virtblk0,num-queues=8,packed=on,bus=pci.1 \
> -drive file=/home/boot.img,if=none,id=drive0,format=raw
>
> smmuv3 event 0x10 log:
> [...]
> [ 1.962656] virtio-pci 0000:02:00.0: Adding to iommu group 0
> [ 1.963150] virtio-pci 0000:02:00.0: enabling device (0000 -> 0002)
> [ 1.964707] virtio_blk virtio0: 6/0/0 default/read/poll queues
> [ 1.965759] virtio_blk virtio0: [vda] 2097152 512-byte logical blocks
> (1.07 GB/1.00 GiB)
> [ 1.966934] arm-smmu-v3 9050000.smmuv3: event 0x10 received:
> [ 1.967442] input: gpio-keys as /devices/platform/gpio-keys/input/input0
> [ 1.967478] arm-smmu-v3 9050000.smmuv3: 0x0000020000000010
> [ 1.968381] clk: Disabling unused clocks
> [ 1.968677] arm-smmu-v3 9050000.smmuv3: 0x0000020000000000
> [ 1.968990] PM: genpd: Disabling unused power domains
> [ 1.969424] arm-smmu-v3 9050000.smmuv3: 0x0000000000000000
> [ 1.969814] ALSA device list:
> [ 1.970240] arm-smmu-v3 9050000.smmuv3: 0x0000000000000000
> [ 1.970471] No soundcards found.
> [ 1.970902] arm-smmu-v3 9050000.smmuv3: event 0x10 received:
> [ 1.971600] arm-smmu-v3 9050000.smmuv3: 0x0000020000000010
> [ 1.971601] arm-smmu-v3 9050000.smmuv3: 0x0000020000000000
> [ 1.971601] arm-smmu-v3 9050000.smmuv3: 0x0000000000000000
> [ 1.971602] arm-smmu-v3 9050000.smmuv3: 0x0000000000000000
> [ 1.971606] arm-smmu-v3 9050000.smmuv3: event 0x10 received:
> [ 1.971607] arm-smmu-v3 9050000.smmuv3: 0x0000020000000010
> [ 1.974202] arm-smmu-v3 9050000.smmuv3: 0x0000020000000000
> [ 1.974634] arm-smmu-v3 9050000.smmuv3: 0x0000000000000000
> [ 1.975005] Freeing unused kernel memory: 10112K
> [ 1.975062] arm-smmu-v3 9050000.smmuv3: 0x0000000000000000
> [ 1.975442] Run init as init process
>
> Another information is that if "maxcpus=3" is removed from the kernel command
> line,
> it will be OK.
>
> I am not sure if there is a bug about vsmmu. It will be very appreciated if
> anyone
> know this issue or can take a look at it.
thanks
-- PMM