Re: Future of icount discussion for next KVM call?

Re: Future of icount discussion for next KVM call?

[Alex Bennée]

[-- Attachment #1: Type: text/plain, Size: 1955 bytes --]

(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.
>
> 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?
>
> --
> Alex Bennée
> Virtualisation Tech Lead @ Linaro
>


-- 
Alex Bennée
Emulation and Virtualisation Tech Lead @ Linaro

[-- Attachment #2: Type: text/html, Size: 2529 bytes --]

Re: Future of icount discussion for next KVM call?

[Juan Quintela]

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.

Re: Future of icount discussion for next KVM call?

[Markus Armbruster]

Juan Quintela <quintela@redhat.com> writes:

> 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.

I think we either need fewer topics per call (ideally one), or strictly
enforced time limits per topic.  I don't fancy meetings where the topic
that made me attend falls off the end.

The former may necessitate more frequent calls.

Re: Future of icount discussion for next KVM call?

[Philippe Mathieu-Daudé]

On 16/2/23 13:20, Markus Armbruster wrote:
> Juan Quintela <quintela@redhat.com> writes:
> 
>> 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?)

I'd rather skip "Single qemu-system binary" for next week agenda.
(In 2 weeks we could discuss CPU topology and shared buses.)

>> - 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.
> 
> I think we either need fewer topics per call (ideally one), or strictly
> enforced time limits per topic.  I don't fancy meetings where the topic
> that made me attend falls off the end.
> 
> The former may necessitate more frequent calls.

IIRC it was said we can have more than every 2 weeks per community
request, otherwise we should try to respect the current cadence to
maintain the current inertia.

Re: Future of icount discussion for next KVM call?

[Alex Bennée]

Markus Armbruster <armbru@redhat.com> writes:

> Juan Quintela <quintela@redhat.com> writes:
>
>> 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.
>
> I think we either need fewer topics per call (ideally one), or strictly
> enforced time limits per topic.  I don't fancy meetings where the topic
> that made me attend falls off the end.

I'm happy to push this out to the next KVM meeting if you want. The main
driver for posting this now was to ensure availability for interested
participants and maybe get some pre-discussion on the list.

> The former may necessitate more frequent calls.

Maybe - the number of agenda items tends to ebb and flow and we seem to
be making good use of the slot now to discuss a wide array of topics.

-- 
Alex Bennée
Virtualisation Tech Lead @ Linaro

Re: Future of icount discussion for next KVM call?

[Juan Quintela]

Alex Bennée <alex.bennee@linaro.org> wrote:
> (replying all because qemu-devel rejected my email again)

Just to see what we are having now:

- single qemu binary moved to next slot (moved to next week?)
  Phillipe proposal
- TDX migration: we have the slides, but no code
  So I guess we can move it to the following slot, when we have a chance
  to look at the code, Wei?
- Markus asked to have only one topic per call
  (and it is reasonable)
- the future of icount cames with documentation to read before the call.

So I think we can do the icount call this week, and discuss here on list
if we move to a weekly call on the same slot.

What do you think?

Later, Juan.

RE: Future of icount discussion for next KVM call?

[Wang, Wei W]

On Thursday, February 16, 2023 9:57 PM, Juan Quintela wrote:
> Just to see what we are having now:
> 
> - single qemu binary moved to next slot (moved to next week?)
>   Phillipe proposal
> - TDX migration: we have the slides, but no code
>   So I guess we can move it to the following slot, when we have a chance
>   to look at the code, Wei?

It's ok to me to continue the discussion on either Feb 21st or March 7th, and I plan to finish some update and share the code before end of next week.

Thanks,
Wei

RE: Future of icount discussion for next KVM call?

[Wang, Wei W]

> -----Original Message-----
> From: Wang, Wei W
> Sent: Thursday, February 16, 2023 10:36 PM
> To: quintela@redhat.com; Alex Bennée <alex.bennee@linaro.org>
> Cc: Paolo Bonzini <pbonzini@redhat.com>; Pavel Dovgalyuk
> <pavel.dovgaluk@ispras.ru>; qemu-devel@nongnu.org; Richard Henderson
> <richard.henderson@linaro.org>; Mark Burton
> <mburton@qti.qualcomm.com>; Bill Mills <bill.mills@linaro.org>; Marco
> Liebel <mliebel@qti.qualcomm.com>; Alexandre Iooss <erdnaxe@crans.org>;
> Mahmoud Mandour <ma.mandourr@gmail.com>; Emilio Cota
> <cota@braap.org>; kvm-devel <kvm@vger.kernel.org>; Philippe Mathieu-
> Daudé <f4bug@amsat.org>
> Subject: RE: Future of icount discussion for next KVM call?
> 
> On Thursday, February 16, 2023 9:57 PM, Juan Quintela wrote:
> > Just to see what we are having now:
> >
> > - single qemu binary moved to next slot (moved to next week?)
> >   Phillipe proposal
> > - TDX migration: we have the slides, but no code
> >   So I guess we can move it to the following slot, when we have a chance
> >   to look at the code, Wei?
> 
> It's ok to me to continue the discussion on either Feb 21st or March 7th, and I
> plan to finish some update and share the code before end of next week.

KVM code can be read here: https://github.com/intel/tdx/  tdx-mig-wip
QEMU code will be shared soon.

RE: Future of icount discussion for next KVM call?

[Wang, Wei W]

On Thursday, February 16, 2023 10:36 PM, Wang, Wei W wrote:
> > On Thursday, February 16, 2023 9:57 PM, Juan Quintela wrote:
> > > Just to see what we are having now:
> > >
> > > - single qemu binary moved to next slot (moved to next week?)
> > >   Phillipe proposal
> > > - TDX migration: we have the slides, but no code
> > >   So I guess we can move it to the following slot, when we have a chance
> > >   to look at the code, Wei?
> >
> > It's ok to me to continue the discussion on either Feb 21st or March
> > 7th, and I plan to finish some update and share the code before end of
> next week.
> 
> KVM code can be read here: https://github.com/intel/tdx/  tdx-mig-wip
> QEMU code will be shared soon.

QEMU code can be read here: https://github.com/intel/qemu-tdx/   tdx-mig-wip