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

Re: [Xen-devel] [PATCH v3 12/13] xen/arm: start the vtimer Xen timers on the processor they should be running on

On Fri, 2013-04-26 at 15:30 +0100, Stefano Stabellini wrote:
> On Thu, 25 Apr 2013, Ian Campbell wrote:
> > On Wed, 2013-04-24 at 20:07 +0100, Stefano Stabellini wrote:
> > > The Xen physical timer emulator and virtual timer driver use two
> > > internal Xen timers: initialize them on the processor the vcpu is
> > > going to be running on, rather than the processor that it's creating the
> > > vcpu.
> > 
> > But this CPU can change as the vcpu migrates around the pcpus, do we not
> > need to handle that case too?
> >
> > Surely we need some code in virt_timer_restore at least? Possibly a call
> > to migrate_timer? Although perhaps there is a less expensive way when we
> > know the timer isn't running?
> I think that the comment above is misleading: the issue is that they
> need to be both initialized with the same starting time and because
> vcpu_vtimer_init is a vcpu initialization function they are called at
> different times, therefore they are going to have a different starting
> time on the two vcpus.
> So the problem is not the physical cpu time but the virtual cpu time.

OK, but in that case why is the value not just stored in the domain
struct instead of being duplicated in each vcpu ?

Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.