Re: [Xen-devel] [RFC v2 1/6] xen/arm: Save and restore support with hvm context hypercalls

[Ian Campbell <Ian.Campbell@xxxxxxxxxx>]

On Thu, 2014-04-17 at 16:06 +0100, Julien Grall wrote:
> I thought a bit more about the {phys,virt}_timer_base.offset.
> 
> When you are migrating a guest, this offset will be invalidated. This
> offset is used to get a relative offset from the Xen timer counter.
> 
> That also made me think the context switch in Xen for the timer looks
> wrong to me.
> 
> When a guest VCPU is context switch, the Xen timer counter continue to
> run. But not CVAL, so the timer_base.offset will drift a bit. It will
> result by setting a wrong timer via set_timer in Xen.
> 
> Did I miss something?

The timer offset is mainly accounting for the fact that the domain is
not booted when the hardware is started.

However time does continue while a VCPU is not scheduled, this is
exposed via the PV "stolen time" mechanism.

Now it is in theory possible to virtualise time differently so that
stolen time is not possible, but unless you want to cope with different
VCPUs seeing different times (because they have been descheduled for
differently lengths of times) then you either need to do gang scheduling
or play other (likely complicated) tricks. With the model we have on ARM
paravirtualising this is the right thing to do.

Not sure what you mean about CVAL (the timer compare val) not running,
when we deschedule a VCPU we figure out when CVAL would have caused the
timer interrupt to fire and setup a Xen timer to make sure we unblock
the VCPU at that point. When we switch back to the VCPU we of course
restore the compare value to what the guest wrote, nothing else would
make sense.

Ian


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