[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [RFC v3 3/6] xen/arm: Add save/restore support for ARM arch timer



On Wed, 2014-05-14 at 13:13 +0100, Julien Grall wrote:
> On 05/14/2014 12:14 PM, Ian Campbell wrote:
> > On Thu, 2014-05-08 at 16:18 -0500, Wei Huang wrote:
> >> This patch implements a save/resore support for ARM architecture
> > 
> > "restore"
> > 
> >> diff --git a/xen/include/public/arch-arm/hvm/save.h 
> >> b/xen/include/public/arch-arm/hvm/save.h
> >> index 421a6f6..8679bfd 100644
> >> --- a/xen/include/public/arch-arm/hvm/save.h
> >> +++ b/xen/include/public/arch-arm/hvm/save.h
> >> @@ -72,10 +72,24 @@ struct hvm_arm_gich_v2
> >>  };
> >>  DECLARE_HVM_SAVE_TYPE(GICH_V2, 3, struct hvm_arm_gich_v2);
> >>  
> >> +/* Two ARM timers (physical and virtual) are saved */
> > 
> > Do you not need to save CNTFRQ and CNTKCTL?
> 
> CNTFRQ is set by the platform and can't change for any guest. If we
> migrate to a platform with a different frequency, then the guest should
> cope with it.

I doubt that (guest coping) will be the case in reality.

CNTFRQ should be saved so that the target platform can either reject the
restore or take steps to emulate the original state. In the short term
this probably means reject.

> IHMO, CNTKCTL should be saved/restored in guest core registers.

I don't see why when there is a timer specific struct.

Ian.


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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.