qemu-devel
[Top][All Lists]
Advanced

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

Re: [PATCH v2 0/7] accel/tcg: remove implied BQL from cpu_handle_interru


From: Robert Foley
Subject: Re: [PATCH v2 0/7] accel/tcg: remove implied BQL from cpu_handle_interrupt/exception path
Date: Thu, 27 Aug 2020 08:38:35 -0400

On Fri, 21 Aug 2020 at 06:56, Cornelia Huck <cohuck@redhat.com> wrote:
> >
> > As the first step in removing the BQL from this path, we will make
> > changes to the core/common functions of cpu_handle_interrupt/exception
> > to drop the holding of the BQL. The holding of the BQL is pushed down
> > to the per-arch implementation code.
>
> I have only skimmed the patches I was cc:ed on so far, but the series
> seems sane to me in general.

Thanks for the feedback !
>
> >
> > This patch goes through several transitions of the code in order to
> > maintain correctness (bisectability).  In order to maintain
> > bisectability across these steps some patches need to touch many
> > files across different arches, however most of the changes are trivial.
> >
> > The general order of the changes is below where each step
> > represents one patch.
> >
> > 1) rename all *_do_interrupt functions to *_do_interrupt_locked
>
> I'm wondering whether this renaming could be done in an automated way
> (e.g. via Coccinelle). Reviewing the method for the renaming is often
> easier than looking at a lot of similar code patterns.

Good point.   We will look into this.

Thanks,
-Rob Foley
>
> >
> > 2) add a new function *_do_interrupt that takes the BQL and calls
> > *_do_interrupt_locked, point ->do_interrupt to it, and remove
> > the BQL from cpu-exec.c's cpu_handle_exception.
> >
> > 3) modify the BQL critical sections around
> > ->cpu_exec_interrupt, so that the BQL critical section covers just the
> > call to ->cpu_exec_interrupt.
> >
> > 4/5) same as 1/2 for ->cpu_exec_interrupt.  This removes the BQL
> > from cpu_handle_exception.
>
> The method of doing this in steps looks fine, although the patches
> produced are a bit unwieldy -- that's something we have to live with, I
> guess.
>



reply via email to

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