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