Message ID | 20230915163254.123338-1-richard.henderson@linaro.org |
---|---|
Headers | show |
Series | accel/tcg: Alternate fix for #1866 | expand |
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(-) >
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~
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~