From: Sean Christopherson <seanjc@google.com>
To: Reiji Watanabe <reijiw@google.com>
Cc: Oliver Upton <oupton@google.com>,
kvm@vger.kernel.org, kvmarm@lists.cs.columbia.edu,
Catalin Marinas <catalin.marinas@arm.com>,
Will Deacon <will@kernel.org>, Marc Zyngier <maz@kernel.org>,
Peter Shier <pshier@google.com>,
David Matlack <dmatlack@google.com>,
Paolo Bonzini <pbonzini@redhat.com>,
linux-arm-kernel@lists.infradead.org,
Jim Mattson <jmattson@google.com>
Subject: Re: [PATCH v8 2/8] KVM: arm64: Separate guest/host counter offset values
Date: Wed, 22 Sep 2021 14:44:26 +0000 [thread overview]
Message-ID: <YUtBSvC97RPD4iRD@google.com> (raw)
In-Reply-To: <CAAeT=Fznwct=D8tk-zRg1SGTa9FqrOrXZ7Boc9yMOnrZ5NPMZw@mail.gmail.com>
On Tue, Sep 21, 2021, Reiji Watanabe wrote:
> Hi Oliver,
>
> On Thu, Sep 16, 2021 at 11:15 AM Oliver Upton <oupton@google.com> wrote:
> > +static void timer_set_guest_offset(struct arch_timer_context *ctxt, u64 offset)
> > +{
> > + struct kvm_vcpu *vcpu = ctxt->vcpu;
> > +
> > + switch (arch_timer_ctx_index(ctxt)) {
> > + case TIMER_VTIMER: {
> > + u64 host_offset = timer_get_offset(ctxt);
> > +
> > + host_offset += offset - __vcpu_sys_reg(vcpu, CNTVOFF_EL2);
> > + __vcpu_sys_reg(vcpu, CNTVOFF_EL2) = offset;
> > + timer_set_offset(ctxt, host_offset);
Really getting into nitpicking territory, but it maybe name this
timer_set_virtual_offset() (assuming v=virtual and p=physical). Based on the
name, I expected this to set a variable literally named guest_offset, but it
reads and writes host_offset. Maintaining the virtual vs. physical terminology
all the way down avoids having direct host vs. guest naming conflicts, i.e.
virtual and host aren't generally though of as mutually exclusive.
> > + break;
> > + }
> > + default:
> > + WARN_ONCE(offset, "timer %ld\n", arch_timer_ctx_index(ctxt));
> > + }
> > +}
> > +
> > u64 kvm_phys_timer_read(void)
> > {
> > return timecounter->cc->read(timecounter->cc);
> > @@ -749,7 +763,8 @@ int kvm_timer_vcpu_reset(struct kvm_vcpu *vcpu)
> >
> > /* Make offset updates for all timer contexts atomic */
> > static void update_timer_offset(struct kvm_vcpu *vcpu,
> > - enum kvm_arch_timers timer, u64 offset)
> > + enum kvm_arch_timers timer, u64 offset,
> > + bool guest_visible)
>
> The name 'guest_visible' looks confusing to me because it also
> affects the type of the 'offset' that its caller needs to specify.
> (The 'offset' must be an offset from the guest's physical counter
> if 'guest_visible' == true, and an offset from the host's virtual
> counter otherwise.)
> Having said that, I don't have a good alternative name for it though...
> IMHO, 'is_host_offset' would be less confusing because it indicates
> what the caller needs to specify.
I'd say ditch the param altogether and just have two separate helpers. Even in
the final code, the callers all pass explicit 'true' or 'false', i.e. the callers
can just as easily call a different function.
Despite the near-identical code, smushing guest and host into the same function
doesn't actually save much, just the function prototype and the local variables.
That'd also avoid having to document/comment what 'true' and 'false' means at the
call sites.
> > {
> > int i;
> > struct kvm *kvm = vcpu->kvm;
> > @@ -758,13 +773,20 @@ static void update_timer_offset(struct kvm_vcpu *vcpu,
> > lockdep_assert_held(&kvm->lock);
> >
> > kvm_for_each_vcpu(i, tmp, kvm)
This needs braces if you keep it as is.
> > - timer_set_offset(vcpu_get_timer(tmp, timer), offset);
> > + if (guest_visible)
> > + timer_set_guest_offset(vcpu_get_timer(tmp, timer),
> > + offset);
Let this poke out, 84 chars isn't the end of the world.
> > + else
> > + timer_set_offset(vcpu_get_timer(tmp, timer), offset);
> >
> > /*
> > * When called from the vcpu create path, the CPU being created is not
> > * included in the loop above, so we just set it here as well.
> > */
Any reason this can't be called from kvm_arch_vcpu_postcreate()? That'd eliminate
the need for the extra handling. The vCPU is technically visible to userspace, but
userspace would have to very intentionally do the wrong thing to cause problems,
and I don't see any obviosu danger to the host.
> > - timer_set_offset(vcpu_get_timer(vcpu, timer), offset);
> > + if (guest_visible)
> > + timer_set_guest_offset(vcpu_get_timer(vcpu, timer), offset);
> > + else
> > + timer_set_offset(vcpu_get_timer(vcpu, timer), offset);
> > }
> >
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2021-09-22 14:46 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-09-16 18:15 [PATCH v8 0/8] KVM: arm64: Add idempotent controls to migrate guest counter Oliver Upton
2021-09-16 18:15 ` [PATCH v8 1/8] KVM: arm64: Refactor update_vtimer_cntvoff() Oliver Upton
2021-09-16 18:15 ` [PATCH v8 2/8] KVM: arm64: Separate guest/host counter offset values Oliver Upton
2021-09-22 4:37 ` Reiji Watanabe
2021-09-22 14:44 ` Sean Christopherson [this message]
2021-09-22 16:17 ` Alexandru Elisei
2021-09-16 18:15 ` [PATCH v8 3/8] KVM: arm64: Make a helper function to get nr of timer regs Oliver Upton
2021-10-05 6:30 ` Andrew Jones
2021-09-16 18:15 ` [PATCH v8 4/8] KVM: arm64: Allow userspace to configure a vCPU's virtual offset Oliver Upton
2021-09-16 18:15 ` [PATCH v8 5/8] arm64: cpufeature: Enumerate support for FEAT_ECV >= 0x2 Oliver Upton
2021-10-13 5:10 ` Reiji Watanabe
2021-09-16 18:15 ` [PATCH v8 6/8] KVM: arm64: Allow userspace to configure a guest's counter-timer offset Oliver Upton
2021-09-22 16:39 ` Reiji Watanabe
2021-09-24 7:20 ` Reiji Watanabe
2021-09-16 18:15 ` [PATCH v8 7/8] KVM: arm64: Configure timer traps in vcpu_load() for VHE Oliver Upton
2021-09-16 18:15 ` [PATCH v8 8/8] KVM: arm64: Emulate physical counter offsetting on non-ECV systems Oliver Upton
2021-09-22 15:27 ` [PATCH v8 0/8] KVM: arm64: Add idempotent controls to migrate guest counter Alexandru Elisei
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=YUtBSvC97RPD4iRD@google.com \
--to=seanjc@google.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=reijiw@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).