Red Hat Bugzilla – Bug 1440619
Reboot guest will induce error message - KVM: Failed to create TCE table for liobn 0x80000001
Last modified: 2017-08-02 00:35:59 EDT
Description of problem: Reboot guest will induce an error message - KVM: Failed to create TCE table for liobn 0x80000001 Version-Release number of selected component (if applicable): kernel-3.10.0-645.el7.ppc64le (hostandguest) qemu-kvm-rhev-2.9.0-0.el7.patchwork201703291116.ppc64le SLOF-20170303-1.git66d250e.el7.noarch How reproducible: 4/4 Steps to Reproduce: 1.boot up guest with the following cli, /usr/libexec/qemu-kvm -name virt-tests-vm1 -sandbox off -machine pseries-rhel7.4.0 -nodefaults -vga std -device virtio-scsi-pci,id=virtio_scsi_pci0,bus=pci.0,addr=03,disable-legacy=off,disable-modern=off -drive id=drive_image1,if=none,cache=none,snapshot=off,aio=native,format=qcow2,file=rhel74-ppc64le-virtio-scsi.qcow2 -device scsi-hd,id=image1,drive=drive_image1 -numa node -qmp tcp:0:4444,server,nowait -vnc :1 -rtc base=utc,clock=host,driftfix=slew -boot order=cdn,once=c,menu=off,strict=off -enable-kvm -monitor stdio -device nec-usb-xhci,id=usb1 -device usb-kbd,id=input0 -device usb-mouse,id=input1 -device usb-tablet,id=input2 -netdev tap,script=/etc/qemu-ifup,downscript=/etc/qemu-down,id=hostnet1,vhost=on -device virtio-net-pci,netdev=hostnet1,id=net1,mac=00:52:11:36:3f:01 2.Within guest reboot From monitor system_reset 3. Actual results: There is an error from monitor (qemu) ststem_restKVM: Failed to create TCE table for liobn 0x80000001 Expected results: There is no any issues Additional info:
QE will have a try on x86 platform the relevant result will be updated to the bug as soon as possible.
Additional analysis for the bug. PPC If add "-m 4096 -smp 4,maxcpus=4,cores=2,threads=1,sockets=2" to the original's cli,the bug won't be reproduced on ppc64le. X86 Besides,if without "-m 4096 -smp 4,maxcpus=4,cores=2,threads=1,sockets=2" the guest *cannot* boot up successfully at all,please have a look on the screen shot. From QE's opinions, we could not simply tell if it was reproducible or not for x86 since the different phenomenon disturbed the result. if with "-m 4096 -smp 4,maxcpus=4,cores=2,threads=1,sockets=2" the bug can not be reproduced on x86 either.
Created attachment 1270436 [details] x86screenshot
(In reply to Min Deng from comment #3) > Additional analysis for the bug. > PPC > If add "-m 4096 -smp 4,maxcpus=4,cores=2,threads=1,sockets=2" to the > original's cli,the bug won't be reproduced on ppc64le. We have two variables here: the CPU topology and RAM size. Please test them separately to confirm which one makes the bug reproducible. > > X86 > Besides,if without "-m 4096 -smp 4,maxcpus=4,cores=2,threads=1,sockets=2" > the guest *cannot* boot up successfully at all,please have a look on the > screen shot. That's probably because the default RAM size on x86 is too small for most guest OSes (128MB). > From QE's opinions, we could not simply tell if it was reproducible or not > for x86 since the different phenomenon disturbed the result. > if with "-m 4096 -smp 4,maxcpus=4,cores=2,threads=1,sockets=2" the > bug can not be reproduced on x86 either. "Failed to create TCE table for liobn" is an error message from ppc-specific code, so this bug is ppc-specific.
(In reply to Eduardo Habkost from comment #6) > (In reply to Min Deng from comment #3) > > Additional analysis for the bug. > > PPC > > If add "-m 4096 -smp 4,maxcpus=4,cores=2,threads=1,sockets=2" to the > > original's cli,the bug won't be reproduced on ppc64le. > > We have two variables here: the CPU topology and RAM size. Please test them > separately to confirm which one makes the bug reproducible. Thanks for the comments and it is steadily reproduced while cli without "-m 4096"
I've had a look at the code around this, and I'm pretty sure the bug is cosmetic only. This basically means that we couldn't enable the KVM acceleration for updates to the guest's IOMMU tables. From the LIOBN quoted I can tell it's on the second window of the primary PCI bus. The second window is the optional 64-bit window which can be configured by the guest. The current KVM acceleration for IOMMU updates only supports 32-bit IOMMU windows, hence the error. qemu will fall back to managing IOMMU updates itself, which should work fine. Hence cosmetic only. Lowering severity accordingly. In fact I already have stage an upstream patch which will remove this error message (and also use the acceleration for 64-bit windows which has been added in more recent kernels). I expect to push this soon after the 2.10 window opens.
Fix included in qemu-kvm-rhev-2.9.0-2.el7
(In reply to Miroslav Rezanina from comment #11) > Fix included in qemu-kvm-rhev-2.9.0-2.el7 The bug can be reproduced on old builds kernel-3.10.0-645.el7.ppc64le (hostandguest) qemu-kvm-rhev-2.9.0-0.el7.patchwork201703291116.ppc64le Verified the bug on the new builds kernel-3.10.0-657.el7.ppc64le qemu-kvm-rhev-2.9.0-2.el7.ppc64le Steps please refer to comment 0 Actual results: There is no any errors Expected results: There is no any errors Draw a conclusion,the bug has been fixed,thanks a lot.
According to comment 13 QE move it to status verified.
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHSA-2017:2392