[Qemu-devel] KVM call minutes for 2013-10-01

[Qemu-devel] KVM call minutes for 2013-10-01

[Juan Quintela]

2013-10-01
----------

- acpi generation patches - ok to merge?
- Talk about qemu reverse executing (1st description was done this week)
  How to handle IO when we want to do reverse execution.
  How this relate to Kemari needs?
  And to icount changes?

a- Save state every second.  When something happens,  you restore to last state and reexecute to current instruction.
   3-4 times more to run,  too slow.
   no IO allowed
b- instead of saving the state of the machine,  fork.  Being careful.
   Fork each time we want one snapshot
   It almost don't affect qemu speed
   Only see what happened,  no way to do the "timeback machine"
   enable/disable as you wish

Issue:
   Saving the icount.  It is not on vmstate.
   Problem with the things that are not deterministic
   icount not used very much there

- exec in reverse: cexe


- Multicore on Multicore:
  TCG has no locking,  no people really working there (Alex Graf?)

Will get the patches upstream as RFC and go from here.

Fork() has the advantage of speed,  and the disadvantage of
.... threads?

Moved to other day to compare with Kemari.

Later,  Juan.

Re: [Qemu-devel] KVM call minutes for 2013-10-01

[Peter Maydell]

On 1 October 2013 23:54, Juan Quintela <quintela@redhat.com> wrote:
> - Multicore on Multicore:
>   TCG has no locking,  no people really working there (Alex Graf?)

Apart from the TCG locking issues (which are conceptually
tractable if anybody cares to try to fix them), the real complication
of multicore-on-multicore is how you handle discrepancies between
the memory models of host and guest, and in particular what
you do if your guest has a stronger memory model than your host:
do you insert barrier insns after every guest load/store? fall back
to not doing mp-on-mp? something else?

-- PMM

Re: [Qemu-devel] KVM call minutes for 2013-10-01

[Stefan Hajnoczi]

On Wed, Oct 02, 2013 at 12:17:35AM +0900, Peter Maydell wrote:
> On 1 October 2013 23:54, Juan Quintela <quintela@redhat.com> wrote:
> > - Multicore on Multicore:
> >   TCG has no locking,  no people really working there (Alex Graf?)
> 
> Apart from the TCG locking issues (which are conceptually
> tractable if anybody cares to try to fix them), the real complication
> of multicore-on-multicore is how you handle discrepancies between
> the memory models of host and guest, and in particular what
> you do if your guest has a stronger memory model than your host:
> do you insert barrier insns after every guest load/store? fall back
> to not doing mp-on-mp? something else?

If you want applications to always work then you need to insert
barriers.  It's expensive.

Stefan