[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <055482bec09cae1ea56f979893c6b67e9d6b26a2.camel@infradead.org>
Date: Wed, 13 Sep 2023 10:31:24 +0200
From: David Woodhouse <dwmw2@...radead.org>
To: Sean Christopherson <seanjc@...gle.com>,
Like Xu <like.xu.linux@...il.com>
Cc: Paolo Bonzini <pbonzini@...hat.com>,
Oliver Upton <oliver.upton@...ux.dev>, kvm@...r.kernel.org,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH v4] KVM: x86/tsc: Don't sync user changes to TSC with
KVM-initiated change
On Fri, 2023-08-11 at 15:59 -0700, Sean Christopherson wrote:
> On Tue, Aug 01, 2023, Like Xu wrote:
> > diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
> > index 278dbd37dab2..eeaf4ad9174d 100644
> > --- a/arch/x86/kvm/x86.c
> > +++ b/arch/x86/kvm/x86.c
> > @@ -2713,7 +2713,7 @@ static void __kvm_synchronize_tsc(struct kvm_vcpu *vcpu, u64 offset, u64 tsc,
> > kvm_track_tsc_matching(vcpu);
> > }
> >
> > -static void kvm_synchronize_tsc(struct kvm_vcpu *vcpu, u64 data)
> > +static void kvm_synchronize_tsc(struct kvm_vcpu *vcpu, u64 data, bool user_initiated)
>
> Rather than pass two somewhat magic values for the KVM-internal call, what about
> making @data a pointer and passing NULL?
Why change that at all?
Userspace used to be able to force a sync by writing zero. You are
removing that from the ABI without any explanation about why; it
doesn't seem necessary for fixing the original issue.
Download attachment "smime.p7s" of type "application/pkcs7-signature" (5965 bytes)
Powered by blists - more mailing lists