All of lore.kernel.org
 help / color / mirror / Atom feed
From: Marcelo Tosatti <mtosatti@redhat.com>
To: Oliver Upton <oupton@google.com>
Cc: Catalin Marinas <catalin.marinas@arm.com>,
	kvm@vger.kernel.org, Will Deacon <will@kernel.org>,
	Marc Zyngier <maz@kernel.org>,
	Raghavendra Rao Anata <rananta@google.com>,
	Peter Shier <pshier@google.com>,
	Sean Christopherson <seanjc@google.com>,
	David Matlack <dmatlack@google.com>,
	Paolo Bonzini <pbonzini@redhat.com>,
	kvmarm@lists.cs.columbia.edu,
	linux-arm-kernel@lists.infradead.org,
	Jim Mattson <jmattson@google.com>
Subject: Re: [PATCH v7 3/6] KVM: x86: Report host tsc and realtime values in KVM_GET_CLOCK
Date: Fri, 20 Aug 2021 09:46:11 -0300	[thread overview]
Message-ID: <20210820124611.GA77176@fuller.cnet> (raw)
In-Reply-To: <20210816001130.3059564-4-oupton@google.com>

On Mon, Aug 16, 2021 at 12:11:27AM +0000, Oliver Upton wrote:
> Handling the migration of TSCs correctly is difficult, in part because
> Linux does not provide userspace with the ability to retrieve a (TSC,
> realtime) clock pair for a single instant in time. In lieu of a more
> convenient facility, KVM can report similar information in the kvm_clock
> structure.
> 
> Provide userspace with a host TSC & realtime pair iff the realtime clock
> is based on the TSC. If userspace provides KVM_SET_CLOCK with a valid
> realtime value, advance the KVM clock by the amount of elapsed time. Do
> not step the KVM clock backwards, though, as it is a monotonic
> oscillator.
> 
> Suggested-by: Paolo Bonzini <pbonzini@redhat.com>
> Signed-off-by: Oliver Upton <oupton@google.com>

This is a good idea. Userspace could check if host and destination
clocks are up to a certain difference and not use the feature if
not appropriate.

Is there a qemu patch for it?

_______________________________________________
kvmarm mailing list
kvmarm@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm

WARNING: multiple messages have this Message-ID (diff)
From: Marcelo Tosatti <mtosatti@redhat.com>
To: Oliver Upton <oupton@google.com>
Cc: kvm@vger.kernel.org, kvmarm@lists.cs.columbia.edu,
	Paolo Bonzini <pbonzini@redhat.com>,
	Sean Christopherson <seanjc@google.com>,
	Marc Zyngier <maz@kernel.org>, Peter Shier <pshier@google.com>,
	Jim Mattson <jmattson@google.com>,
	David Matlack <dmatlack@google.com>,
	Ricardo Koller <ricarkol@google.com>,
	Jing Zhang <jingzhangos@google.com>,
	Raghavendra Rao Anata <rananta@google.com>,
	James Morse <james.morse@arm.com>,
	Alexandru Elisei <alexandru.elisei@arm.com>,
	Suzuki K Poulose <suzuki.poulose@arm.com>,
	linux-arm-kernel@lists.infradead.org,
	Andrew Jones <drjones@redhat.com>, Will Deacon <will@kernel.org>,
	Catalin Marinas <catalin.marinas@arm.com>
Subject: Re: [PATCH v7 3/6] KVM: x86: Report host tsc and realtime values in KVM_GET_CLOCK
Date: Fri, 20 Aug 2021 09:46:11 -0300	[thread overview]
Message-ID: <20210820124611.GA77176@fuller.cnet> (raw)
In-Reply-To: <20210816001130.3059564-4-oupton@google.com>

On Mon, Aug 16, 2021 at 12:11:27AM +0000, Oliver Upton wrote:
> Handling the migration of TSCs correctly is difficult, in part because
> Linux does not provide userspace with the ability to retrieve a (TSC,
> realtime) clock pair for a single instant in time. In lieu of a more
> convenient facility, KVM can report similar information in the kvm_clock
> structure.
> 
> Provide userspace with a host TSC & realtime pair iff the realtime clock
> is based on the TSC. If userspace provides KVM_SET_CLOCK with a valid
> realtime value, advance the KVM clock by the amount of elapsed time. Do
> not step the KVM clock backwards, though, as it is a monotonic
> oscillator.
> 
> Suggested-by: Paolo Bonzini <pbonzini@redhat.com>
> Signed-off-by: Oliver Upton <oupton@google.com>

This is a good idea. Userspace could check if host and destination
clocks are up to a certain difference and not use the feature if
not appropriate.

Is there a qemu patch for it?


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

WARNING: multiple messages have this Message-ID (diff)
From: Marcelo Tosatti <mtosatti@redhat.com>
To: Oliver Upton <oupton@google.com>
Cc: kvm@vger.kernel.org, kvmarm@lists.cs.columbia.edu,
	Paolo Bonzini <pbonzini@redhat.com>,
	Sean Christopherson <seanjc@google.com>,
	Marc Zyngier <maz@kernel.org>, Peter Shier <pshier@google.com>,
	Jim Mattson <jmattson@google.com>,
	David Matlack <dmatlack@google.com>,
	Ricardo Koller <ricarkol@google.com>,
	Jing Zhang <jingzhangos@google.com>,
	Raghavendra Rao Anata <rananta@google.com>,
	James Morse <james.morse@arm.com>,
	Alexandru Elisei <alexandru.elisei@arm.com>,
	Suzuki K Poulose <suzuki.poulose@arm.com>,
	linux-arm-kernel@lists.infradead.org,
	Andrew Jones <drjones@redhat.com>, Will Deacon <will@kernel.org>,
	Catalin Marinas <catalin.marinas@arm.com>
Subject: Re: [PATCH v7 3/6] KVM: x86: Report host tsc and realtime values in KVM_GET_CLOCK
Date: Fri, 20 Aug 2021 09:46:11 -0300	[thread overview]
Message-ID: <20210820124611.GA77176@fuller.cnet> (raw)
In-Reply-To: <20210816001130.3059564-4-oupton@google.com>

On Mon, Aug 16, 2021 at 12:11:27AM +0000, Oliver Upton wrote:
> Handling the migration of TSCs correctly is difficult, in part because
> Linux does not provide userspace with the ability to retrieve a (TSC,
> realtime) clock pair for a single instant in time. In lieu of a more
> convenient facility, KVM can report similar information in the kvm_clock
> structure.
> 
> Provide userspace with a host TSC & realtime pair iff the realtime clock
> is based on the TSC. If userspace provides KVM_SET_CLOCK with a valid
> realtime value, advance the KVM clock by the amount of elapsed time. Do
> not step the KVM clock backwards, though, as it is a monotonic
> oscillator.
> 
> Suggested-by: Paolo Bonzini <pbonzini@redhat.com>
> Signed-off-by: Oliver Upton <oupton@google.com>

This is a good idea. Userspace could check if host and destination
clocks are up to a certain difference and not use the feature if
not appropriate.

Is there a qemu patch for it?


  reply	other threads:[~2021-08-20 12:46 UTC|newest]

Thread overview: 61+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-08-16  0:11 [PATCH v7 0/6] KVM: x86: Add idempotent controls for migrating system counter state Oliver Upton
2021-08-16  0:11 ` Oliver Upton
2021-08-16  0:11 ` Oliver Upton
2021-08-16  0:11 ` [PATCH v7 1/6] KVM: x86: Fix potential race in KVM_GET_CLOCK Oliver Upton
2021-08-16  0:11   ` Oliver Upton
2021-08-16  0:11   ` Oliver Upton
2021-08-19 18:24   ` Marcelo Tosatti
2021-08-19 18:24     ` Marcelo Tosatti
2021-08-19 18:24     ` Marcelo Tosatti
2021-08-20 18:22     ` Oliver Upton
2021-08-20 18:22       ` Oliver Upton
2021-08-20 18:22       ` Oliver Upton
2021-08-16  0:11 ` [PATCH v7 2/6] KVM: x86: Create helper methods for KVM_{GET,SET}_CLOCK ioctls Oliver Upton
2021-08-16  0:11   ` Oliver Upton
2021-08-16  0:11   ` Oliver Upton
2021-08-16  0:11 ` [PATCH v7 3/6] KVM: x86: Report host tsc and realtime values in KVM_GET_CLOCK Oliver Upton
2021-08-16  0:11   ` Oliver Upton
2021-08-16  0:11   ` Oliver Upton
2021-08-20 12:46   ` Marcelo Tosatti [this message]
2021-08-20 12:46     ` Marcelo Tosatti
2021-08-20 12:46     ` Marcelo Tosatti
2021-09-24  8:30     ` Paolo Bonzini
2021-09-24  8:30       ` Paolo Bonzini
2021-09-24  8:30       ` Paolo Bonzini
2021-08-16  0:11 ` [PATCH v7 4/6] KVM: x86: Take the pvclock sync lock behind the tsc_write_lock Oliver Upton
2021-08-16  0:11   ` Oliver Upton
2021-08-16  0:11   ` Oliver Upton
2021-09-02 19:22   ` Sean Christopherson
2021-09-02 19:22     ` Sean Christopherson
2021-09-02 19:22     ` Sean Christopherson
2021-08-16  0:11 ` [PATCH v7 5/6] KVM: x86: Refactor tsc synchronization code Oliver Upton
2021-08-16  0:11   ` Oliver Upton
2021-08-16  0:11   ` Oliver Upton
2021-09-02 19:21   ` Sean Christopherson
2021-09-02 19:21     ` Sean Christopherson
2021-09-02 19:21     ` Sean Christopherson
2021-09-02 19:41     ` Oliver Upton
2021-09-02 19:41       ` Oliver Upton
2021-09-02 19:41       ` Oliver Upton
2021-09-24  9:28     ` Paolo Bonzini
2021-09-24  9:28       ` Paolo Bonzini
2021-09-24  9:28       ` Paolo Bonzini
2021-08-16  0:11 ` [PATCH v7 6/6] KVM: x86: Expose TSC offset controls to userspace Oliver Upton
2021-08-16  0:11   ` Oliver Upton
2021-08-16  0:11   ` Oliver Upton
2021-08-23 20:56   ` Oliver Upton
2021-08-23 20:56     ` Oliver Upton
2021-08-23 20:56     ` Oliver Upton
2021-08-26 12:48     ` Marcelo Tosatti
2021-08-26 12:48       ` Marcelo Tosatti
2021-08-26 12:48       ` Marcelo Tosatti
2021-08-26 20:27       ` Oliver Upton
2021-08-26 20:27         ` Oliver Upton
2021-08-26 20:27         ` Oliver Upton
2021-08-29  8:25         ` Paolo Bonzini
2021-09-02 19:23 ` [PATCH v7 0/6] KVM: x86: Add idempotent controls for migrating system counter state Sean Christopherson
2021-09-02 19:23   ` Sean Christopherson
2021-09-02 19:23   ` Sean Christopherson
2021-09-02 19:45   ` Oliver Upton
2021-09-02 19:45     ` Oliver Upton
2021-09-02 19:45     ` Oliver Upton

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20210820124611.GA77176@fuller.cnet \
    --to=mtosatti@redhat.com \
    --cc=catalin.marinas@arm.com \
    --cc=dmatlack@google.com \
    --cc=jmattson@google.com \
    --cc=kvm@vger.kernel.org \
    --cc=kvmarm@lists.cs.columbia.edu \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=maz@kernel.org \
    --cc=oupton@google.com \
    --cc=pbonzini@redhat.com \
    --cc=pshier@google.com \
    --cc=rananta@google.com \
    --cc=seanjc@google.com \
    --cc=will@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.