From mboxrd@z Thu Jan 1 00:00:00 1970 From: Julien Grall Subject: Re: [RFC v2 1/6] xen/arm: Save and restore support with hvm context hypercalls Date: Mon, 12 May 2014 13:04:45 +0100 Message-ID: <5370B8DD.6000600@linaro.org> References: <1397595918-30419-1-git-send-email-w1.huang@samsung.com> <1397595918-30419-2-git-send-email-w1.huang@samsung.com> <534FEDFD.7030202@linaro.org> <1399886168.561.95.camel@kazak.uk.xensource.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <1399886168.561.95.camel@kazak.uk.xensource.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Ian Campbell Cc: Wei Huang , stefano.stabellini@eu.citrix.com, andrew.cooper3@citrix.com, jaeyong.yoo@samsung.com, xen-devel@lists.xen.org, yjhyun.yoo@samsung.com List-Id: xen-devel@lists.xenproject.org On 05/12/2014 10:16 AM, Ian Campbell wrote: > 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. After reading your explanation and the ARM ARM again, I think I mingled CNT (the counter) and CVAL (the compare val). Thank you for the explanation. -- Julien Grall