mbox series

[v2,0/3] accel/tcg: Alternate fix for #1866

Message ID 20230915163254.123338-1-richard.henderson@linaro.org
Headers show
Series accel/tcg: Alternate fix for #1866 | expand

Message

Richard Henderson Sept. 15, 2023, 4:32 p.m. UTC
Supercedes: 20230914174436.1597356-1-richard.henderson@linaro.org
("[PATCH 0/6] accel/tcg: Always require can_do_io (#1866)")

An alternate fix for #1866 without touching can_do_io, and is
perhaps a bit cleaner and clearer.

Instead, the current cpu checks whether an address space update
is required on each entry to the slow path.  This certainly
catches all i/o.  It easily works for the sequential case of
two i/o, the first of which changes the address space and the
second of which requires the new address space.

I've done a tiny bit of performance testing between the two
solutions and it seems to be a wash.  So now it's simply a
matter of cleanliness.


r~


Richard Henderson (3):
  softmmu: Use cpu->created in tcg_commit
  softmmu: Introduce AddressSpaceDispatch generation numbers
  softmmu: Introduce cpu_address_space_sync

 include/exec/memory.h |  6 ++++++
 accel/tcg/cputlb.c    |  2 ++
 softmmu/physmem.c     | 46 ++++++++++++++++++++++++++++++++++++-------
 3 files changed, 47 insertions(+), 7 deletions(-)

Comments

Philippe Mathieu-Daudé Sept. 15, 2023, 4:55 p.m. UTC | #1
On 15/9/23 18:32, Richard Henderson wrote:
> Supercedes: 20230914174436.1597356-1-richard.henderson@linaro.org
> ("[PATCH 0/6] accel/tcg: Always require can_do_io (#1866)")

Patches 1-4 (5?) are cleanups although, isn't it?

> An alternate fix for #1866 without touching can_do_io, and is
> perhaps a bit cleaner and clearer.
> 
> Instead, the current cpu checks whether an address space update
> is required on each entry to the slow path.  This certainly
> catches all i/o.  It easily works for the sequential case of
> two i/o, the first of which changes the address space and the
> second of which requires the new address space.
> 
> I've done a tiny bit of performance testing between the two
> solutions and it seems to be a wash.  So now it's simply a
> matter of cleanliness.
> 
> 
> r~
> 
> 
> Richard Henderson (3):
>    softmmu: Use cpu->created in tcg_commit
>    softmmu: Introduce AddressSpaceDispatch generation numbers
>    softmmu: Introduce cpu_address_space_sync
> 
>   include/exec/memory.h |  6 ++++++
>   accel/tcg/cputlb.c    |  2 ++
>   softmmu/physmem.c     | 46 ++++++++++++++++++++++++++++++++++++-------
>   3 files changed, 47 insertions(+), 7 deletions(-)
>
Richard Henderson Sept. 15, 2023, 5:18 p.m. UTC | #2
On 9/15/23 09:55, Philippe Mathieu-Daudé wrote:
> On 15/9/23 18:32, Richard Henderson wrote:
>> Supercedes: 20230914174436.1597356-1-richard.henderson@linaro.org
>> ("[PATCH 0/6] accel/tcg: Always require can_do_io (#1866)")
> 
> Patches 1-4 (5?) are cleanups although, isn't it?

Yes, 1-4 are good cleanups, and 5 is probably a bug fix
(though I don't see the hang without patch 6), despite
the fact that the hang is *with* icount (replay tests).


r~
Richard Henderson Sept. 15, 2023, 6:54 p.m. UTC | #3
On 9/15/23 09:32, Richard Henderson wrote:
> Supercedes: 20230914174436.1597356-1-richard.henderson@linaro.org
> ("[PATCH 0/6] accel/tcg: Always require can_do_io (#1866)")
> 
> An alternate fix for #1866 without touching can_do_io, and is
> perhaps a bit cleaner and clearer.
> 
> Instead, the current cpu checks whether an address space update
> is required on each entry to the slow path.  This certainly
> catches all i/o.  It easily works for the sequential case of
> two i/o, the first of which changes the address space and the
> second of which requires the new address space.
> 
> I've done a tiny bit of performance testing between the two
> solutions and it seems to be a wash.  So now it's simply a
> matter of cleanliness.

Ho hum, this doesn't fix the x86_64 ovmf issue also quoted in #1866.


r~