qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: 答复: [PATCH v1 1/2] system/cpus: Fix pause_all_vcpus() under concurre


From: Peter Maydell
Subject: Re: 答复: [PATCH v1 1/2] system/cpus: Fix pause_all_vcpus() under concurrent environment
Date: Tue, 19 Mar 2024 14:56:47 +0000

On Tue, 19 Mar 2024 at 14:46, David Hildenbrand <david@redhat.com> wrote:
>
> On 19.03.24 15:23, Peter Maydell wrote:
> > On Tue, 19 Mar 2024 at 09:24, David Hildenbrand <david@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_ynQ@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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]