On 24/02/16 12:31, Juan Quintela wrote:
>> I don't really understand the question. Migration has no equivalent
>> in real hardware, so there's no "real" behaviour to mimic. If we
>> freeze the TB during migration, then the guest's clock will get out of
>> sync with wall clock time, and in a produ
On Wed, Feb 24, 2016 at 01:31:05PM +0100, Juan Quintela wrote:
> David Gibson wrote:
> > On Tue, Feb 23, 2016 at 09:27:09PM +, Mark Cave-Ayland wrote:
> >> On 03/02/16 04:59, David Gibson wrote:
> >>
> >> >> Going back to your earlier email you suggested that the host timebase is
> >> >> alwa
David Gibson wrote:
> On Tue, Feb 23, 2016 at 09:27:09PM +, Mark Cave-Ayland wrote:
>> On 03/02/16 04:59, David Gibson wrote:
>>
>> >> Going back to your earlier email you suggested that the host timebase is
>> >> always continuously running, even when the guest is paused. But then
>> >> resu
On Tue, Feb 23, 2016 at 09:27:09PM +, Mark Cave-Ayland wrote:
> On 03/02/16 04:59, David Gibson wrote:
>
> >> Going back to your earlier email you suggested that the host timebase is
> >> always continuously running, even when the guest is paused. But then
> >> resuming the guest then the time
On 03/02/16 04:59, David Gibson wrote:
>> Going back to your earlier email you suggested that the host timebase is
>> always continuously running, even when the guest is paused. But then
>> resuming the guest then the timebase must jump in the guest regardless?
>>
>> If this is the case then this
> Am 03.02.2016 um 06:59 schrieb David Gibson :
>
>> On Tue, Feb 02, 2016 at 11:41:40PM +, Mark Cave-Ayland wrote:
>> On 01/02/16 00:52, David Gibson wrote:
>>
Thanks for more pointers - I think I'm slowly getting there. My current
thoughts are that the basic migration algorithm i
On Tue, Feb 02, 2016 at 11:41:40PM +, Mark Cave-Ayland wrote:
> On 01/02/16 00:52, David Gibson wrote:
>
> >> Thanks for more pointers - I think I'm slowly getting there. My current
> >> thoughts are that the basic migration algorithm is doing the right thing
> >> in that it works out the numb
On 01/02/16 00:52, David Gibson wrote:
>> Thanks for more pointers - I think I'm slowly getting there. My current
>> thoughts are that the basic migration algorithm is doing the right thing
>> in that it works out the number of host ticks different between source
>> and destination.
>
> Sorry, I'
On Tue, Jan 26, 2016 at 10:31:19PM +, Mark Cave-Ayland wrote:
> On 25/01/16 11:10, David Gibson wrote:
>
> > Um.. so the migration duration is a complete red herring, regardless
> > of the units.
> >
> > Remember, we only ever compute the guest timebase value at the moment
> > the guest reque
On 26/01/16 22:31, Mark Cave-Ayland wrote:
> For a typical savevm/loadvm pair I see something like this:
>
> savevm:
>
> tb->guest_timebase = 26281306490558
> qemu_clock_get_ns(QEMU_CLOCK_VIRTUAL) = 7040725511
>
> loadvm:
>
> cpu_get_host_ticks() = 26289847005259
> tb_off_adj = -8540514701
> q
On 25/01/16 11:10, David Gibson wrote:
> Um.. so the migration duration is a complete red herring, regardless
> of the units.
>
> Remember, we only ever compute the guest timebase value at the moment
> the guest requests it - actually maintaining a current timebase value
> makes sense in hardware
On Mon, Jan 25, 2016 at 05:48:02AM +, Mark Cave-Ayland wrote:
> On 18/01/16 04:51, David Gibson wrote:
>
> > On Fri, Jan 15, 2016 at 05:46:10PM +, Mark Cave-Ayland wrote:
> >> On 12/01/16 02:44, David Gibson wrote:
> >>
> > In other words, isn't this just skipping the decrementer inter
On 18/01/16 04:51, David Gibson wrote:
> On Fri, Jan 15, 2016 at 05:46:10PM +, Mark Cave-Ayland wrote:
>> On 12/01/16 02:44, David Gibson wrote:
>>
> In other words, isn't this just skipping the decrementer interrupts at
> the qemu level rather than the guest level?
>
> It seem
13 matches
Mail list logo
