From mboxrd@z Thu Jan  1 00:00:00 1970
From: Julien Grall <julien.grall@linaro.org>
Subject: Re: [RFC v2 1/6] xen/arm: Save and restore support with
 hvm context hypercalls
Date: Thu, 17 Apr 2014 16:06:37 +0100
Message-ID: <534FEDFD.7030202@linaro.org>
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>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Return-path: <xen-devel-bounces@lists.xen.org>
In-Reply-To: <1397595918-30419-2-git-send-email-w1.huang@samsung.com>
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: Wei Huang <w1.huang@samsung.com>, 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

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.

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?

-- 
Julien Grall