[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <Zo6r3if6rTERxnwl@google.com>
Date: Wed, 10 Jul 2024 08:42:22 -0700
From: Sean Christopherson <seanjc@...gle.com>
To: Reinette Chatre <reinette.chatre@...el.com>
Cc: isaku.yamahata@...el.com, pbonzini@...hat.com, erdemaktas@...gle.com,
vkuznets@...hat.com, vannapurve@...gle.com, jmattson@...gle.com,
mlevitsk@...hat.com, xiaoyao.li@...el.com, chao.gao@...el.com,
rick.p.edgecombe@...el.com, yuan.yao@...el.com, kvm@...r.kernel.org,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH V9 0/2] KVM: x86: Make bus clock frequency for vAPIC timer configurable
On Fri, Jun 28, 2024, Reinette Chatre wrote:
> Hi Sean,
>
> On 6/28/24 3:55 PM, Sean Christopherson wrote:
> > On Wed, 12 Jun 2024 11:16:10 -0700, Reinette Chatre wrote:
> > > Changes from v8:
> > > - v8: https://lore.kernel.org/lkml/cover.1718043121.git.reinette.chatre@intel.com/
> > > - Many changes to new udelay() utility patch as well as the APIC bus
> > > frequency test aimed to make it more robust (additional ASSERTs,
> > > consistent types, eliminate duplicate code, etc.) and useful with
> > > support for more user configuration. Please refer to individual patches for
> > > detailed changes.
> > > - Series applies cleanly to next branch of kvm-x86 with HEAD
> > > e4e9e1067138e5620cf0500c3e5f6ebfb9d322c8.
> > >
> > > [...]
> >
> > Applied to kvm-x86 misc, with all the changes mentioned in my earlier replies.
> > I'm out next week, and don't want to merge the KVM changes without these tests,
> > hence the rushed application.
> >
> > Please holler if you disagree with anything (or if I broke something). I won't
> > respond until July 8th at the earliest, but worst case scenario we can do fixup
> > patches after 6.11-rc1.
>
> Thank you very much for taking the time to make the changes and apply the patches.
> All the changes look good to me and passes my testing.
>
> Now that the x86 udelay() utility no longer use cpu_relax(), should ARM
> and RISC-V's udelay() be modified to match in this regard? I can prepare
> (unable to test) changes for you to consider on your return.
I don't think so? IIUC, arm64's "yield", used by cpu_relax() doesn't trigger the
"on spin" exists. Such exist are only triggered by "wfet" and friends.
Powered by blists - more mailing lists