On Tue, 19 Mar 2024 at 14:46, David Hildenbrand <da...@redhat.com> wrote: > > On 19.03.24 15:23, Peter Maydell wrote: > > On Tue, 19 Mar 2024 at 09:24, David Hildenbrand <da...@redhat.com> wrote: > >> I spotted new pause_all_vcpus() / resume_all_vcpus() calls in > >> hw/intc/arm_gicv3_kvm.c and > >> thought they would be the problematic bit. > >> > >> Yeah, that's going to be problematic. Further note that a lot of code does > >> not expect > >> that the BQL is suddenly dropped. > > > > Agreed; we already have one nasty set of bugs in the framebuffer > > devices because a function drops the BQL briefly: > > https://lore.kernel.org/qemu-devel/CAFEAcA9odnPo2LPip295Uztri7JfoVnQbkJ=wn+k8dqneb_...@mail.gmail.com/T/#u > > so let's avoid introducing any more of a similar kind. > > > > Side note, the pause_all_vcpus()/resume_all_vcpus() calls in > > hw/i386/vapic.c are probably a bit suspect for similar reasons. > > Exactly my thoughts. But there, it was less clear "why" it is even > required. It's only performed for KVM. > > Do we also just want to stop KVM threads from executing instructions?, > so blocking KVM ioctls might be a reasonable "replacement"? Really not sure.
I think the vapic code wants to stop other threads from executing instructions while it's patching them, yes. -- PMM