Hi Richard, Are you planning to get this patchset merged in this window? If so, I can give it a respin on top of the current master.
Anyway, before doing so we should fix the issue around CF_COUNT_MASK that Pranith reported: On Wed, Aug 30, 2017 at 10:43:28 -0400, Pranith Kumar wrote: > On Tue, Aug 29, 2017 at 5:16 PM, Emilio G. Cota <c...@braap.org> wrote: > > On Sun, Aug 27, 2017 at 18:15:50 -0400, Pranith Kumar wrote: > >> Hi Emilio, > >> > >> On Fri, Jul 21, 2017 at 1:59 AM, Emilio G. Cota <c...@braap.org> wrote: > >> > This will enable us to decouple code translation from the value > >> > of parallel_cpus at any given time. It will also help us minimize > >> > TB flushes when generating code via EXCP_ATOMIC. > >> > > >> > Note that the declaration of parallel_cpus is brought to exec-all.h > >> > to be able to define there the "curr_cflags" inline. > >> > > >> > Signed-off-by: Emilio G. Cota <c...@braap.org> > >> > >> I was testing a winxp image today and I bisected a infinite loop to > >> this commit. The loop happens both with and without mttcg, so I think > >> it has got to do with something else. > > > > Can you test the below? It lets me boot ubuntu, otherwise it reliably > > chokes on a 'rep movsb' *very* early (doesn't even get to grub). > > > > This discusson on v2 might be relevant (I added CF_COUNT_MASK as a > > result of it, but it seems I have to revisit that): > > https://lists.gnu.org/archive/html/qemu-devel/2017-07/msg06456.html > > > > Anyway let me know if this fixes it for you. Thanks for testing! > > > > Yes, this fixes the issue for me. My quick-fix is just not to check those bits, but as you pointed out during v3's review the whole thing is a little bit fragile if we don't check them. Should we just go with the CF_NOCHAIN flag that you proposed? If so, do you want me to give that approach a go, or you prefer to do it yourself? Thanks, Emilio
