From mboxrd@z Thu Jan  1 00:00:00 1970
From: Wei Huang <w1.huang@samsung.com>
Subject: Re: [RFC v2 1/6] xen/arm: Save and restore support with
 hvm context hypercalls
Date: Thu, 17 Apr 2014 11:55:37 -0500
Message-ID: <53500789.8070706@samsung.com>
References: <w1.huang@samsung.com>
	<1397595918-30419-1-git-send-email-w1.huang@samsung.com>
	<1397595918-30419-2-git-send-email-w1.huang@samsung.com>
	<534FEDFD.7030202@linaro.org>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Content-Transfer-Encoding: 7bit
Return-path: <xen-devel-bounces@lists.xen.org>
In-reply-to: <534FEDFD.7030202@linaro.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org
To: Julien Grall <julien.grall@linaro.org>, ian.campbell@citrix.com, stefano.stabellini@eu.citrix.com
Cc: andrew.cooper3@citrix.com, yjhyun.yoo@samsung.com, jaeyong.yoo@samsung.com, xen-devel@lists.xen.org
List-Id: xen-devel@lists.xenproject.org

On 04/17/2014 10:06 AM, Julien Grall wrote:
> Hello Wei,
>
> On 04/15/2014 10:05 PM, Wei Huang wrote:
>> +static int hvm_vtimer_load_ctxt(struct domain *d, hvm_domain_context_t *h)
>> +{
>> +    int vcpuid;
>> +    struct hvm_hw_timer ctxt;
>> +    struct vcpu *v;
>> +    struct vtimer *t = NULL;
>> +
>> +    /* Which vcpu is this? */
>> +    vcpuid = hvm_load_instance(h);
>> +
>> +    if ( vcpuid >= d->max_vcpus || (v = d->vcpu[vcpuid]) == NULL )
>> +    {
>> +        dprintk(XENLOG_G_ERR, "HVM restore: dom%u has no vcpu%u\n",
>> +                d->domain_id, vcpuid);
>> +        return -EINVAL;
>> +    }
>> +
>> +    if ( hvm_load_entry(TIMER, h, &ctxt) != 0 )
>> +        return -EINVAL;
>> +
>> +    if ( ctxt.type == TIMER_TYPE_VIRT )
>> +    {
>> +        t = &v->arch.virt_timer;
>> +        d->arch.virt_timer_base.offset = ctxt.vtb_offset;
>> +    }
>> +    else
>> +    {
>> +        t = &v->arch.phys_timer;
>> +        d->arch.phys_timer_base.offset = ctxt.vtb_offset;
>
> 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.
>
Agreed.
> 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.
>
I need to examine the code more carefully. But by skimming through 
vtimer.c, it looks like this is the case: the missing ticks were not 
compensated.
> Did I miss something?
>