From: Eugenio Perez Martin <eperezma@redhat.com>
To: Peter Xu <peterx@redhat.com>, qemu-devel@nongnu.org
Cc: Peter Maydell <peter.maydell@linaro.org>,
Yan Zhao <yan.y.zhao@intel.com>,
Juan Quintela <quintela@redhat.com>,
Jason Wang <jasowang@redhat.com>,
"Michael S. Tsirkin" <mst@redhat.com>,
Eric Auger <eric.auger@redhat.com>, Avi Kivity <avi@redhat.com>,
Paolo Bonzini <pbonzini@redhat.com>
Subject: Re: [RFC v3 0/1] memory: Delete assertion in memory_region_unregister_iommu_notifier
Date: Tue, 11 Aug 2020 20:10:44 +0200 [thread overview]
Message-ID: <CAJaqyWf24F8ERAuvYj+0Xv=+cYj4v1MCmvCmQFTqcfLVYYCVuQ@mail.gmail.com> (raw)
In-Reply-To: <20200811175533.7359-1-eperezma@redhat.com>
On Tue, Aug 11, 2020 at 7:56 PM Eugenio Pérez <eperezma@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
.
next prev parent reply other threads:[~2020-08-11 18:12 UTC|newest]
Thread overview: 68+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-06-26 6:41 [RFC v2 0/1] memory: Delete assertion in memory_region_unregister_iommu_notifier Eugenio Pérez
2020-06-26 6:41 ` [RFC v2 1/1] " Eugenio Pérez
2020-06-26 21:29 ` Peter Xu
2020-06-27 7:26 ` Yan Zhao
2020-06-27 12:57 ` Peter Xu
2020-06-28 1:36 ` Yan Zhao
2020-06-28 7:03 ` Jason Wang
2020-06-28 14:47 ` Peter Xu
2020-06-29 5:51 ` Jason Wang
2020-06-29 13:34 ` Peter Xu
2020-06-30 2:41 ` Jason Wang
2020-06-30 8:29 ` Jason Wang
2020-06-30 9:21 ` Michael S. Tsirkin
2020-06-30 9:23 ` Jason Wang
2020-06-30 15:20 ` Peter Xu
2020-07-01 8:11 ` Jason Wang
2020-07-01 12:16 ` Peter Xu
2020-07-01 12:30 ` Jason Wang
2020-07-01 12:41 ` Peter Xu
2020-07-02 3:00 ` Jason Wang
2020-06-30 15:39 ` Peter Xu
2020-07-01 8:09 ` Jason Wang
2020-07-02 3:01 ` Jason Wang
2020-07-02 15:45 ` Peter Xu
2020-07-03 7:24 ` Jason Wang
2020-07-03 13:03 ` Peter Xu
2020-07-07 8:03 ` Jason Wang
2020-07-07 19:54 ` Peter Xu
2020-07-08 5:42 ` Jason Wang
2020-07-08 14:16 ` Peter Xu
2020-07-09 5:58 ` Jason Wang
2020-07-09 14:10 ` Peter Xu
2020-07-10 6:34 ` Jason Wang
2020-07-10 13:30 ` Peter Xu
2020-07-13 4:04 ` Jason Wang
2020-07-16 1:00 ` Peter Xu
2020-07-16 2:54 ` Jason Wang
2020-07-17 14:18 ` Peter Xu
2020-07-20 4:02 ` Jason Wang
2020-07-20 13:03 ` Peter Xu
2020-07-21 6:20 ` Jason Wang
2020-07-21 15:10 ` Peter Xu
2020-08-03 16:00 ` Eugenio Pérez
2020-08-04 20:30 ` Peter Xu
2020-08-05 5:45 ` Jason Wang
2020-08-11 17:01 ` Eugenio Perez Martin
2020-08-11 17:10 ` Eugenio Perez Martin
2020-06-29 15:05 ` [RFC v2 0/1] " Paolo Bonzini
2020-07-03 7:39 ` Eugenio Perez Martin
2020-07-03 10:10 ` Paolo Bonzini
2020-08-11 17:55 ` [RFC v3 " Eugenio Pérez
2020-08-11 17:55 ` [RFC v3 1/1] memory: Skip bad range assertion if notifier supports arbitrary masks Eugenio Pérez
2020-08-12 2:24 ` Jason Wang
2020-08-12 8:49 ` Eugenio Perez Martin
2020-08-18 14:24 ` Eugenio Perez Martin
2020-08-19 7:15 ` Jason Wang
2020-08-19 8:22 ` Eugenio Perez Martin
2020-08-19 9:36 ` Jason Wang
2020-08-19 15:50 ` Peter Xu
2020-08-20 2:28 ` Jason Wang
2020-08-21 14:12 ` Peter Xu
2020-09-01 3:05 ` Jason Wang
2020-09-01 19:35 ` Peter Xu
2020-09-02 5:13 ` Jason Wang
2020-08-11 18:10 ` Eugenio Perez Martin [this message]
2020-08-11 19:27 ` [RFC v3 0/1] memory: Delete assertion in memory_region_unregister_iommu_notifier Peter Xu
2020-08-12 14:33 ` Eugenio Perez Martin
2020-08-12 21:12 ` Peter Xu
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CAJaqyWf24F8ERAuvYj+0Xv=+cYj4v1MCmvCmQFTqcfLVYYCVuQ@mail.gmail.com' \
--to=eperezma@redhat.com \
--cc=avi@redhat.com \
--cc=eric.auger@redhat.com \
--cc=jasowang@redhat.com \
--cc=mst@redhat.com \
--cc=pbonzini@redhat.com \
--cc=peter.maydell@linaro.org \
--cc=peterx@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=quintela@redhat.com \
--cc=yan.y.zhao@intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).