Alex Bennée <alex.ben...@linaro.org> wrote: > (replying all because qemu-devel rejected my email again) > > On Thu, 16 Feb 2023 at 10:19, Alex Bennée <alex.ben...@linaro.org> wrote: > >> Hi Juan, >> >> Do we have an agenda for next weeks KVM call yet? If there is space I'd >> like to take some time to discuss the future direction of icount.
For next week we have: - more single binary qemu (philippe?) - TDX migration from intel. We asked them on the previous call to change their design to transfer stuff through migration channels and not create a new channel. But I haven't heard from intel. (wei?) They agreed to send the slides and post the code before continue discussion. And now I like the title of you topic - Future Direction of icount O:-) So, I will recommend 20 minutes each if Wei shows up, or 30/30 for the rest. What do the rest of the people think. >> Specifically I believe there might be some proposals for how we could >> support icount with MTTCG worth discussing. From my point of view icount >> provides too things: >> >> - a sense of time vaguely related to execution rather than wall clock >> - determinism >> >> I would love to divorce the former from icount and punt it to plugins. >> The plugin would be free to instrument as heavily or lightly as it sees >> fit and provide its best guess as to guest time on demand. I wrote this >> idea up as a card in Linaro's JIRA if anyone is interested: >> >> https://linaro.atlassian.net/browse/QEMU-481 >> >> Being able to punt cost modelling and sense of time into plugins would >> allow the core icount support to concentrate on determinism. Then any >> attempt to enable icount for MTTCG would then have to ensure it stays >> deterministic. >> >> Richard and I have discussed the problem a few times and weren't sure it >> was solvable but I'm totally open to hearing ideas on how to do it. >> Fundamentally I think we would have to ensure any TB's doing IO would >> have to execute in an exclusive context. The TCG code already has >> mechanisms to ensure all IO is only done at the end of blocks so it >> doesn't seem a huge leap to ensure we execute those blocks exclusively. >> However there is still the problem of what to do about other pure >> computation threads getting ahead or behind of the IO blocks on >> subsequent runs. >> >> Anyway does anyone else have ideas to bring to the discussion? Hat on to you O:-) Open discussion with a Jira Epic and a good introduction. I am sorry that I am not an expert (or even newbie) on that part of qemu to give apport anything. Thanks, Juan.