Re: [Qemu-devel] [RFC 0/8] arm AioContext with its own timer stuff

[Kevin Wolf <kwolf@redhat.com>]

Am 26.07.2013 um 10:43 hat Stefan Hajnoczi geschrieben:
> On Thu, Jul 25, 2013 at 07:53:33PM +0100, Alex Bligh wrote:
> > 
> > 
> > --On 25 July 2013 14:32:59 +0200 Jan Kiszka <jan.kiszka@siemens.com> wrote:
> > 
> > >>I would happily at a QEMUClock of each type to AioContext. They are after
> > >>all pretty lightweight.
> > >
> > >What's the point of adding tones of QEMUClock instances? Considering
> > >proper abstraction, how are they different for each AioContext? Will
> > >they run against different clock sources, start/stop at different times?
> > >If the answer is "they have different timer list", then fix this
> > >incorrect abstraction.
> > 
> > Even if I fix the abstraction, there is a question of whether it is
> > necessary to have more than one timer list per AioContext, because
> > the timer list is fundamentally per clock-source. I am currently
> > just using QEMU_CLOCK_REALTIME as that's what the block drivers normally
> > want. Will block drivers ever want timers from a different clock source?
> 
> block.c and block/qed.c use vm_clock because block drivers should not do
> guest I/O while the vm is stopped.  This is especially true during live
> migration where it's important to hand off the image file from the
> source host to the destination host with good cache consistency.  The
> source host is not allowed to modify the image file anymore once the
> destination host has resumed the guest.
> 
> Block jobs use rt_clock because they aren't considered guest I/O.

But considering your first paragraph, why is it safe to let block jobs
running while we're migrating? Do we really do that? It sounds unsafe to
me.

Kevin