On Tue, Aug 11, 2020 at 7:56 PM Eugenio Pérez <epere...@redhat.com> wrote: > > I am able to hit this assertion when a Red Hat 7 guest virtio_net device > raises an "Invalidation" of all the TLB entries. This happens in the > guest's startup if 'intel_iommu=on' argument is passed to the guest > kernel and right IOMMU/ATS devices are declared in qemu's command line. > > Command line: > /home/qemu/x86_64-softmmu/qemu-system-x86_64 -name \ > guest=rhel7-test,debug-threads=on -machine \ > pc-q35-5.1,accel=kvm,usb=off,dump-guest-core=off,kernel_irqchip=split \ > -cpu \ > Broadwell,vme=on,ss=on,vmx=on,f16c=on,rdrand=on,hypervisor=on,arat=on,tsc-adjust=on,umip=on,arch-capabilities=on,xsaveopt=on,pdpe1gb=on,abm=on,skip-l1dfl-vmentry=on,rtm=on,hle=on > \ > -m 8096 -realtime mlock=off -smp 2,sockets=2,cores=1,threads=1 -uuid \ > d022ecbf-679e-4755-87ce-eb87fc5bbc5d -display none -no-user-config \ > -nodefaults -rtc base=utc,driftfix=slew -global \ > kvm-pit.lost_tick_policy=delay -no-hpet -no-shutdown -global \ > ICH9-LPC.disable_s3=1 -global ICH9-LPC.disable_s4=1 -boot strict=on \ > -device intel-iommu,intremap=on,device-iotlb=on -device \ > pcie-root-port,port=0x8,chassis=1,id=pci.1,bus=pcie.0,multifunction=on,addr=0x1 > \ > -device \ > pcie-root-port,port=0x9,chassis=2,id=pci.2,bus=pcie.0,addr=0x1.0x1 \ > -device \ > pcie-root-port,port=0xa,chassis=3,id=pci.3,bus=pcie.0,addr=0x1.0x2 \ > -device \ > pcie-root-port,port=0xb,chassis=4,id=pci.4,bus=pcie.0,addr=0x1.0x3 \ > -device \ > pcie-root-port,port=0xc,chassis=5,id=pci.5,bus=pcie.0,addr=0x1.0x4 \ > -device \ > pcie-root-port,port=0xd,chassis=6,id=pci.6,bus=pcie.0,addr=0x1.0x5 \ > -device \ > pcie-root-port,port=0xe,chassis=7,id=pci.7,bus=pcie.0,addr=0x1.0x6 \ > -device qemu-xhci,p2=15,p3=15,id=usb,bus=pci.2,addr=0x0 -device \ > virtio-serial-pci,id=virtio-serial0,bus=pci.3,addr=0x0 -drive \ > file=/home/virtio-test2.qcow2,format=qcow2,if=none,id=drive-virtio-disk0 \ > -device \ > virtio-blk-pci,scsi=off,bus=pci.4,addr=0x0,drive=drive-virtio-disk0,id=virtio-disk0,bootindex=1 > \ > -netdev tap,id=hostnet0,vhost=on,vhostforce=on -device \ > virtio-net-pci,netdev=hostnet0,id=net0,mac=52:54:00:0d:1d:f2,bus=pci.1,addr=0x0,iommu_platform=on,ats=on > \ > -device virtio-balloon-pci,id=balloon0,bus=pci.5,addr=0x0 -object \ > rng-random,id=objrng0,filename=/dev/urandom -device \ > virtio-rng-pci,rng=objrng0,id=rng0,bus=pci.6,addr=0x0 -s -msg \ > timestamp=on > > Full backtrace: > > at /home/qemu/hw/i386/intel_iommu.c:2468 > (mr=0x555557609330, addr=136, value=0x7ffde5dfe478, size=4, shift=0, > mask=4294967295, attrs=...) at /home/qemu/memory.c:483 > (addr=136, value=0x7ffde5dfe478, size=4, access_size_min=4, > access_size_max=8, access_fn= > 0x555555883d38 <memory_region_write_accessor>, mr=0x555557609330, > attrs=...) at /home/qemu/memory.c:544 > at /home/qemu/memory.c:1476 > (fv=0x7ffde00935d0, addr=4275634312, attrs=..., ptr=0x7ffff7ff0028, > len=4, addr1=136, l=4, mr=0x555557609330) at /home/qemu/exec.c:3146 > at /home/qemu/exec.c:3186 > (as=0x5555567ca640 <address_space_memory>, addr=4275634312, attrs=..., > buf=0x7ffff7ff0028, len=4) at /home/qemu/exec.c:3277 > (as=0x5555567ca640 <address_space_memory>, addr=4275634312, attrs=..., > buf=0x7ffff7ff0028, len=4, is_write=true) > at /home/qemu/exec.c:3287 > > -- > > Tested with vhost-net, with a linux bridge to forward packets. > Forwarding with vhostuser interfaces + dpdk-testpmd io forwarding mode seems > broken also in v5.1.0-rc3. > > v3: Skip the assertion in case notifier is a IOTLB one, since they can manage > arbitrary ranges. Using a flag in the notifier for now, as Peter > suggested. > > v2: Actually delete assertion instead of just commenting out using C99 > > Eugenio Pérez (1): > memory: Skip bad range assertion if notifier supports arbitrary masks > > hw/virtio/vhost.c | 2 +- > include/exec/memory.h | 2 ++ > softmmu/memory.c | 10 ++++++++-- > 3 files changed, 11 insertions(+), 3 deletions(-) > > -- > 2.18.1 > >
Using this patch as a reference, I'm having problems to understand: - I'm not sure that the flag name expresses clearly the notifier capability. - What would be the advantages of using another field (NotifierType?) in the notifier to express that it accepts arbitrary ranges for unmapping? (If I understood correctly Jason's proposal) - Is it possible (or advisable) to skip all the page splitting in vtd_page_walk if the memory range notifier supports these arbitrary ranges? What would be the disadvantages? (Maybe in a future patch). It seems it is advisable to me, but I would like to double confirm. I think I don't miss anything, please let me know otherwise. Thanks! PS: Sorry I forgot to recover the backtrace properly, it will be included in the next RFC/patch version. In case somebody misses it, it is here: https://lists.gnu.org/archive/html/qemu-devel/2020-07/msg01015.html .
