On Thu, 2020-12-03 at 17:18 -0300, Marcelo Tosatti wrote:
> On Thu, Dec 03, 2020 at 01:39:42PM +0200, Maxim Levitsky wrote:
> > On Tue, 2020-12-01 at 16:48 -0300, Marcelo Tosatti wrote:
> > > On Tue, Dec 01, 2020 at 02:30:39PM +0200, Maxim Levitsky wrote:
> > > > On Mon, 2020-11-30 at 16:16 -0300,
On Thu, Dec 03, 2020 at 01:39:42PM +0200, Maxim Levitsky wrote:
> On Tue, 2020-12-01 at 16:48 -0300, Marcelo Tosatti wrote:
> > On Tue, Dec 01, 2020 at 02:30:39PM +0200, Maxim Levitsky wrote:
> > > On Mon, 2020-11-30 at 16:16 -0300, Marcelo Tosatti wrote:
> > > > Hi Maxim,
> > > >
> > > > On
On Tue, 2020-12-01 at 20:35 +0100, Thomas Gleixner wrote:
> On Mon, Nov 30 2020 at 15:35, Maxim Levitsky wrote:
> > The idea of masterclock is that when the host TSC is synchronized
> > (or as kernel call it, stable), and the guest TSC is synchronized as well,
> > then we can base the kvmclock, on
On Tue, 2020-12-01 at 08:19 -0800, Andy Lutomirski wrote:
> > On Dec 1, 2020, at 6:01 AM, Thomas Gleixner wrote:
> >
> > On Mon, Nov 30 2020 at 16:16, Marcelo Tosatti wrote:
> > > Not really. The synchronization logic tries to sync TSCs during
> > > BIOS boot (and CPU hotplug), because the TSC
On Tue, 2020-12-01 at 12:02 -0300, Marcelo Tosatti wrote:
> On Tue, Dec 01, 2020 at 02:48:11PM +0100, Thomas Gleixner wrote:
> > On Mon, Nov 30 2020 at 16:16, Marcelo Tosatti wrote:
> > > > Besides, Linux guests don't sync the TSC via IA32_TSC write,
> > > > but rather use IA32_TSC_ADJUST which
On 01/12/20 20:35, Thomas Gleixner wrote:
This makes the random error in calculation of this value invariant
across vCPUS, and allows the guest to do kvmclock calculation in userspace
(vDSO) since kvmclock parameters are vCPU invariant.
That's not the case today? OMG!
It's optional. If the
On Tue, 2020-12-01 at 16:48 -0300, Marcelo Tosatti wrote:
> On Tue, Dec 01, 2020 at 02:30:39PM +0200, Maxim Levitsky wrote:
> > On Mon, 2020-11-30 at 16:16 -0300, Marcelo Tosatti wrote:
> > > Hi Maxim,
> > >
> > > On Mon, Nov 30, 2020 at 03:35:57PM +0200, Maxim Levitsky wrote:
> > > > Hi!
> > > >
On Tue, Dec 01, 2020 at 02:30:39PM +0200, Maxim Levitsky wrote:
> On Mon, 2020-11-30 at 16:16 -0300, Marcelo Tosatti wrote:
> > Hi Maxim,
> >
> > On Mon, Nov 30, 2020 at 03:35:57PM +0200, Maxim Levitsky wrote:
> > > Hi!
> > >
> > > This is the first version of the work to make TSC migration more
On Mon, Nov 30 2020 at 15:35, Maxim Levitsky wrote:
> The idea of masterclock is that when the host TSC is synchronized
> (or as kernel call it, stable), and the guest TSC is synchronized as well,
> then we can base the kvmclock, on the same pair of
> (host time in nsec, host tsc value), for all
On Tue, Dec 01, 2020 at 02:48:11PM +0100, Thomas Gleixner wrote:
> On Mon, Nov 30 2020 at 16:16, Marcelo Tosatti wrote:
> >> Besides, Linux guests don't sync the TSC via IA32_TSC write,
> >> but rather use IA32_TSC_ADJUST which currently doesn't participate
> >> in the tsc sync heruistics.
> >
> >
> On Dec 1, 2020, at 6:01 AM, Thomas Gleixner wrote:
>
> On Mon, Nov 30 2020 at 16:16, Marcelo Tosatti wrote:
>> Not really. The synchronization logic tries to sync TSCs during
>> BIOS boot (and CPU hotplug), because the TSC values are loaded
>> sequentially, say:
>>
>> CPUrealtime
On Mon, Nov 30 2020 at 16:16, Marcelo Tosatti wrote:
> Not really. The synchronization logic tries to sync TSCs during
> BIOS boot (and CPU hotplug), because the TSC values are loaded
> sequentially, say:
>
> CPU realtimeTSC val
> vcpu0 0 usec 0
> vcpu1
On Mon, Nov 30 2020 at 16:16, Marcelo Tosatti wrote:
>> Besides, Linux guests don't sync the TSC via IA32_TSC write,
>> but rather use IA32_TSC_ADJUST which currently doesn't participate
>> in the tsc sync heruistics.
>
> Linux should not try to sync the TSC with IA32_TSC_ADJUST. It expects
> the
On Mon, 2020-11-30 at 16:16 -0300, Marcelo Tosatti wrote:
> Hi Maxim,
>
> On Mon, Nov 30, 2020 at 03:35:57PM +0200, Maxim Levitsky wrote:
> > Hi!
> >
> > This is the first version of the work to make TSC migration more accurate,
> > as was defined by Paulo at:
> >
Hi Maxim,
On Mon, Nov 30, 2020 at 03:35:57PM +0200, Maxim Levitsky wrote:
> Hi!
>
> This is the first version of the work to make TSC migration more accurate,
> as was defined by Paulo at:
> https://www.spinics.net/lists/kvm/msg225525.html
Description from Oliver's patch:
"To date, VMMs have
On 30/11/20 17:54, Andy Lutomirski wrote:
I*do think* however that we should redefine KVM_CLOCK_TSC_STABLE
in the documentation to state that it only guarantees invariance if the guest
doesn't mess with its own TSC.
Also I think we should consider enabling the X86_FEATURE_TSC_RELIABLE
in the
On Mon, Nov 30, 2020 at 5:36 AM Maxim Levitsky wrote:
>
> Hi!
>
> This is the first version of the work to make TSC migration more accurate,
> as was defined by Paulo at:
> https://www.spinics.net/lists/kvm/msg225525.html
>
> I have a few thoughts about the kvm masterclock synchronization,
>
This is the summary of few things that I think are relevant.
Best regards,
Maxim Levitsky
# Random unsynchronized ramblings about the TSC in KVM/Linux
## The KVM's master clock
Under assumption that
a. Host TSC is synchronized and stable (wasn't marked as unstable).
b. Guest TSC is
Hi!
This is the first version of the work to make TSC migration more accurate,
as was defined by Paulo at:
https://www.spinics.net/lists/kvm/msg225525.html
I have a few thoughts about the kvm masterclock synchronization,
which relate to the Paulo's proposal that I implemented.
The idea of
19 matches
Mail list logo
