Re: Future of icount discussion for next KVM call?

[Juan Quintela <quintela@redhat.com>]

Alex Bennée <alex.bennee@linaro.org> wrote:
> (replying all because qemu-devel rejected my email again)
>
> On Thu, 16 Feb 2023 at 10:19, Alex Bennée <alex.bennee@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.