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

[Stefano Stabellini <stefano.stabellini@xxxxxxxxxxxxx>]

On Fri, 26 Apr 2013, Ian Campbell wrote:
> 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 ?

That's right, in fact I am making that change now

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel