On 19-01-25 21:04:10, Jon DeVree wrote:
>
> * KVM_FEATURE_CLOCKSOURCE_STABLE_BIT is always set by the hypervisor
> starting with Linux v2.6.35 - 371bcf646d17 ("KVM: x86: Tell the guest
> we'll warn it about tsc stability")
> * PVCLOCK_TSC_STABLE_BIT is set starting in Linux v3.8 but only if th
On Mon, Jan 07, 2019 at 20:04:41 -0500, Pavel Tatashin wrote:
> I did exactly the same sequence on Kaby Lake CPU and could not
> reproduce it. What is your host CPU?
>
I have some machines which display this bug and others that don't, so I
was able to figure out the difference between their confi
Pavel Tatashin wrote on Mon, Jan 07, 2019:
> I did exactly the same sequence on Kaby Lake CPU and could not
> reproduce it. What is your host CPU?
skylake consumer laptop CPU: Intel(R) Core(TM) i7-6500U CPU @ 2.50GHz
I don't have any kaby lake around; I have access to older servers though...
--
I did exactly the same sequence on Kaby Lake CPU and could not
reproduce it. What is your host CPU?
Thank you,
Pasha
On Mon, Jan 7, 2019 at 6:48 PM Dominique Martinet
wrote:
>
> Pavel Tatashin wrote on Mon, Jan 07, 2019:
> > I could not reproduce the problem. Did you suspend to memory between
>
Pavel Tatashin wrote on Mon, Jan 07, 2019:
> I could not reproduce the problem. Did you suspend to memory between
> wake ups? Does this time jump happen every time, even if your laptop
> sleeps for a minute?
I'm not sure I understand "suspend to memory between the wake ups".
The full sequence is:
On Thu, Jan 3, 2019 at 6:43 PM Dominique Martinet
wrote:
>
> Pavel Tatashin wrote on Thu, Jan 03, 2019:
> > Could you please send the config file and qemu arguments that were
> > used to reproduce this problem.
>
> Running qemu by hand, nothing fancy e.g. this works:
>
> # qemu-system-x86_64 -m 1G
Hi Salvatore,
>p.s.: my earlier reply to you seem to have been rejected and never
> reached you, hope this one does now.
if you sent from Googlemail, it may reach me in the next weeks or
never *shrug* they don’t play nice with greylisting. The -submitter
or @d.o works, though. I’m following
Pavel Tatashin wrote on Thu, Jan 03, 2019:
> Could you please send the config file and qemu arguments that were
> used to reproduce this problem.
Running qemu by hand, nothing fancy e.g. this works:
# qemu-system-x86_64 -m 1G -smp 4 -drive
file=/root/kvm-wrapper/disks/f2.img,if=virtio -serial mo
Could you please send the config file and qemu arguments that were
used to reproduce this problem.
Thank you,
Pasha
On Wed, Jan 2, 2019 at 3:20 PM Salvatore Bonaccorso wrote:
>
> Hi,
>
> On Tue, Nov 06, 2018 at 06:35:36AM -0500, Steven Sistare wrote:
> > Pavel has a new email address, cc'd - ste
Hi,
On Tue, Nov 06, 2018 at 06:35:36AM -0500, Steven Sistare wrote:
> Pavel has a new email address, cc'd - steve
>
> On 11/6/2018 12:42 AM, Dominique Martinet wrote:
> > (added various kvm/virtualization lists in Cc as well as qemu as I don't
> > know who's "wrong" here)
> >
> > Pavel Tatashin
Pavel has a new email address, cc'd - steve
On 11/6/2018 12:42 AM, Dominique Martinet wrote:
> (added various kvm/virtualization lists in Cc as well as qemu as I don't
> know who's "wrong" here)
>
> Pavel Tatashin wrote on Thu, Jul 19, 2018:
>> Allow sched_clock() to be used before schec_clock_in
(added various kvm/virtualization lists in Cc as well as qemu as I don't
know who's "wrong" here)
Pavel Tatashin wrote on Thu, Jul 19, 2018:
> Allow sched_clock() to be used before schec_clock_init() is called.
> This provides with a way to get early boot timestamps on machines with
> unstable clo
12 matches
Mail list logo
