[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Future of icount discussion for next KVM call?
From: |
Juan Quintela |
Subject: |
Re: Future of icount discussion for next KVM call? |
Date: |
Thu, 16 Feb 2023 11:56:27 +0100 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/28.2 (gnu/linux) |
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.