On 28/11/2016 17:36, Marcelo Tosatti wrote:
> If the source masterclock is disabled, then the guest does
> not enable the optimization to not use a global variable
> to guarantee monotonicity. Therefore there will be no
> time backwards events (the timer backwards events crashed
> guests, and
On Mon, Nov 28, 2016 at 02:47:18PM +0100, Paolo Bonzini wrote:
>
>
> On 17/11/2016 13:16, Marcelo Tosatti wrote:
> > What QEMU wants is to use KVM_GET_CLOCK at pre_save independently
> > of whether masterclock is enabled or not... it just depends
> > on KVM_GET_CLOCK being correct for the masterc
On 28/11/2016 15:28, Eduardo Habkost wrote:
> > +s->src_use_reliable_get_clock = data.flags & KVM_CLOCK_TSC_STABLE;
>
> I still don't understand the reasoning behind
> kvm_has_adjust_clock_stable() vs (flags & KVM_CLOCK_TSC_STABLE),
> but on either case, updating src_use_reliable_get_clock i
On Mon, Nov 28, 2016 at 02:47:18PM +0100, Paolo Bonzini wrote:
>
>
> On 17/11/2016 13:16, Marcelo Tosatti wrote:
> > What QEMU wants is to use KVM_GET_CLOCK at pre_save independently
> > of whether masterclock is enabled or not... it just depends
> > on KVM_GET_CLOCK being correct for the masterc
On 17/11/2016 13:16, Marcelo Tosatti wrote:
> What QEMU wants is to use KVM_GET_CLOCK at pre_save independently
> of whether masterclock is enabled or not... it just depends
> on KVM_GET_CLOCK being correct for the masterclock case
> (108b249c453dd7132599ab6dc7e435a7036c193f).
>
> So a "reliable
On 17/11/2016 13:16, Marcelo Tosatti wrote:
> On Mon, Nov 14, 2016 at 04:15:18PM -0200, Marcelo Tosatti wrote:
>> On Mon, Nov 14, 2016 at 06:20:29PM +0100, Paolo Bonzini wrote:
>>>
>>>
>>> On 14/11/2016 18:13, Marcelo Tosatti wrote:
On Mon, Nov 14, 2016 at 05:43:33PM +0100, Paolo Bonzini wro
On Mon, Nov 14, 2016 at 04:15:18PM -0200, Marcelo Tosatti wrote:
> On Mon, Nov 14, 2016 at 06:20:29PM +0100, Paolo Bonzini wrote:
> >
> >
> > On 14/11/2016 18:13, Marcelo Tosatti wrote:
> > > On Mon, Nov 14, 2016 at 05:43:33PM +0100, Paolo Bonzini wrote:
> > >>
> > >>
> > >> On 14/11/2016 16:40,
On Mon, Nov 14, 2016 at 06:20:29PM +0100, Paolo Bonzini wrote:
>
>
> On 14/11/2016 18:13, Marcelo Tosatti wrote:
> > On Mon, Nov 14, 2016 at 05:43:33PM +0100, Paolo Bonzini wrote:
> >>
> >>
> >> On 14/11/2016 16:40, Marcelo Tosatti wrote:
> >>> static bool kvmclock_src_use_reliable_get_clock(void
On 14/11/2016 18:13, Marcelo Tosatti wrote:
> On Mon, Nov 14, 2016 at 05:43:33PM +0100, Paolo Bonzini wrote:
>>
>>
>> On 14/11/2016 16:40, Marcelo Tosatti wrote:
>>> static bool kvmclock_src_use_reliable_get_clock(void *opaque)
>>> {
>>> KVMClockState *s = opaque;
>>>
>>> /*
>>> * On
On Mon, Nov 14, 2016 at 05:43:33PM +0100, Paolo Bonzini wrote:
>
>
> On 14/11/2016 16:40, Marcelo Tosatti wrote:
> > static bool kvmclock_src_use_reliable_get_clock(void *opaque)
> > {
> > KVMClockState *s = opaque;
> >
> > /*
> > * On machine types that support reliable KVM_GET_CLO
On 14/11/2016 16:40, Marcelo Tosatti wrote:
> static bool kvmclock_src_use_reliable_get_clock(void *opaque)
> {
> KVMClockState *s = opaque;
>
> /*
> * On machine types that support reliable KVM_GET_CLOCK,
> * if host kernel does provide reliable KVM_GET_CLOCK,
> * set src
On Mon, Nov 14, 2016 at 03:09:46PM +0100, Juan Quintela wrote:
> Marcelo Tosatti wrote:
> > Check for KVM_CAP_ADJUST_CLOCK capability KVM_CLOCK_TSC_STABLE, which
> > indicates that KVM_GET_CLOCK returns a value as seen by the guest at
> > that moment.
> >
> > For new machine types, use this value
On Mon, Nov 14, 2016 at 04:00:38PM +0100, Paolo Bonzini wrote:
>
>
> On 14/11/2016 15:50, Marcelo Tosatti wrote:
> > Well, i didnt want to mix the meaning of the variables:
> >
> > +/* whether machine supports reliable KVM_GET_CLOCK */
> > +bool mach_use_reliable_get_clock;
> > +
> > +
On 14/11/2016 15:50, Marcelo Tosatti wrote:
> Well, i didnt want to mix the meaning of the variables:
>
> +/* whether machine supports reliable KVM_GET_CLOCK */
> +bool mach_use_reliable_get_clock;
> +
> +/* whether source host supported reliable KVM_GET_CLOCK */
> +bool src_use_
On Mon, Nov 14, 2016 at 03:22:02PM +0100, Paolo Bonzini wrote:
>
>
> On 14/11/2016 15:00, Marcelo Tosatti wrote:
> > On Mon, Nov 14, 2016 at 02:54:38PM +0100, Paolo Bonzini wrote:
> >>
> >>
> >> On 14/11/2016 13:36, Marcelo Tosatti wrote:
> >>> +/* local (running VM) restore */
> >>> +
On 14/11/2016 15:00, Marcelo Tosatti wrote:
> On Mon, Nov 14, 2016 at 02:54:38PM +0100, Paolo Bonzini wrote:
>>
>>
>> On 14/11/2016 13:36, Marcelo Tosatti wrote:
>>> +/* local (running VM) restore */
>>> +if (s->clock_valid) {
>>> +/*
>>> + * if host does n
Paolo Bonzini wrote:
> On 14/11/2016 13:36, Marcelo Tosatti wrote:
>> +/* local (running VM) restore */
>> +if (s->clock_valid) {
>> +/*
>> + * if host does not support reliable KVM_GET_CLOCK,
>> + * read kvmclock value from memory
>> +
Marcelo Tosatti wrote:
> Check for KVM_CAP_ADJUST_CLOCK capability KVM_CLOCK_TSC_STABLE, which
> indicates that KVM_GET_CLOCK returns a value as seen by the guest at
> that moment.
>
> For new machine types, use this value rather than reading
> from guest memory.
>
> This reduces kvmclock differe
On Mon, Nov 14, 2016 at 02:54:38PM +0100, Paolo Bonzini wrote:
>
>
> On 14/11/2016 13:36, Marcelo Tosatti wrote:
> > +/* local (running VM) restore */
> > +if (s->clock_valid) {
> > +/*
> > + * if host does not support reliable KVM_GET_CLOCK,
> > +
On 14/11/2016 13:36, Marcelo Tosatti wrote:
> +/* local (running VM) restore */
> +if (s->clock_valid) {
> +/*
> + * if host does not support reliable KVM_GET_CLOCK,
> + * read kvmclock value from memory
> + */
> +if (!kv
Check for KVM_CAP_ADJUST_CLOCK capability KVM_CLOCK_TSC_STABLE, which
indicates that KVM_GET_CLOCK returns a value as seen by the guest at
that moment.
For new machine types, use this value rather than reading
from guest memory.
This reduces kvmclock difference on migration from 5s to 0.1s
(when
21 matches
Mail list logo
