[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Stefan Hajnoczi
Subject: Re: [Qemu-devel] [RFC 0/8] arm AioContext with its own timer stuff
Date: Fri, 26 Jul 2013 10:43:45 +0200
User-agent: Mutt/1.5.21 (2010-09-15)

On Thu, Jul 25, 2013 at 07:53:33PM +0100, Alex Bligh wrote:
> --On 25 July 2013 14:32:59 +0200 Jan Kiszka <address@hidden> 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.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]