For migration to work we need to save (and later restore) the state of
each core's virtual generic timer.
Since this is per VCPU, we can use the [gs]et_one_reg ioctl and export
the three needed registers (control, counter, compare value).
Though they live in cp15 space, we don't use the existing li
On Fri, Dec 13, 2013 at 02:23:26PM +0100, Andre Przywara wrote:
> For migration to work we need to save (and later restore) the state of
> each core's virtual generic timer.
> Since this is per VCPU, we can use the [gs]et_one_reg ioctl and export
> the three needed registers (control, counter, comp
On 12/13/2013 09:10 PM, Christoffer Dall wrote:
On Fri, Dec 13, 2013 at 02:23:26PM +0100, Andre Przywara wrote:
For migration to work we need to save (and later restore) the state of
each core's virtual generic timer.
Since this is per VCPU, we can use the [gs]et_one_reg ioctl and export
the thr
On Fri, Dec 13, 2013 at 09:35:49PM +0100, Andre Przywara wrote:
> On 12/13/2013 09:10 PM, Christoffer Dall wrote:
> >On Fri, Dec 13, 2013 at 02:23:26PM +0100, Andre Przywara wrote:
> >>For migration to work we need to save (and later restore) the state of
> >>each core's virtual generic timer.
> >>
On 13/12/13 20:35, Andre Przywara wrote:
> On 12/13/2013 09:10 PM, Christoffer Dall wrote:
>> On Fri, Dec 13, 2013 at 02:23:26PM +0100, Andre Przywara wrote:
>>> For migration to work we need to save (and later restore) the state of
>>> each core's virtual generic timer.
>>> Since this is per VCPU,
On Tue, Dec 17, 2013 at 11:20:20AM +, Marc Zyngier wrote:
> On 13/12/13 20:35, Andre Przywara wrote:
> > On 12/13/2013 09:10 PM, Christoffer Dall wrote:
> >> On Fri, Dec 13, 2013 at 02:23:26PM +0100, Andre Przywara wrote:
> >>> For migration to work we need to save (and later restore) the state
