[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH v3 4/4] x86/APIC: make connections between seemingly arbitrary numbers


  • To: Jan Beulich <jbeulich@xxxxxxxx>
  • From: Roger Pau Monné <roger.pau@xxxxxxxxxx>
  • Date: Mon, 14 Mar 2022 09:56:00 +0100
  • Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=citrix.com; dmarc=pass action=none header.from=citrix.com; dkim=pass header.d=citrix.com; arc=none
  • Arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=poKvJJ6nelKY3DJA2ef1LFVjaP9p0DQCrGcNsDXoJ/U=; b=NxIdylsBkRY9lx1/04AxQaG3mvdjOnJE2JZbLYN3lNhum55lH6CTxTbQBwHMWHyBylfdj7bzDafmtx8m59MzaHYxFB8vKTexu65NOXighxDvxpT5ODU/8IoK7obU9kkN2BTzIZOOHijhMBLXq6L8v7IMB7X35A/OtideFgMtfMdbVBDzm9oKIH8lwz2tdJXrGSfJtKrAU9/LLog4S+L3JVY+bkvdH2eT0QgOjw9mUlJl7V0bGipdtmvPvGnCZdmhUw6cB6qaD0utBFkU/e5PTYPm9Ic8+US1dnOGAtabBKpu+YIlCaqJLfuvLIH0ANDEi40XwbxHqX2ehESqOHbUWw==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=TloaKuuuzjY0PQH29kJew8n+2xjrgK/o4t7TKmiBgU2CshlgN5kwIB6ulzAZwMFc2wMab1urAmHPfDzspT7xXyRf9xXPR9xCfpu67KRMTgDNWMrFUbK7Xzqdp3Z2MHguCvaqzrJ41X9lnNvJBu0cIE9nslEwgrG1+izqsGMpBM++WID9U8hnc1dki455CTg2Y1iU2wuF0+F14MDrDE/5hiUYITeJjyQXleuQDNPBKaZBGDuQmO1fJxtLYlRpByGkWPb3NrSGiODClOOkUlGXASLBreBXdxcwrXKcDQQh7M2U+fKUI5PX8Wf7tpkZHGOEtZthvHOxNoBaji1D9q210A==
  • Authentication-results: esa2.hc3370-68.iphmx.com; dkim=pass (signature verified) header.i=@citrix.onmicrosoft.com
  • Cc: "xen-devel@xxxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxxx>, "Andrew Cooper" <andrew.cooper3@xxxxxxxxxx>, Wei Liu <wl@xxxxxxx>
  • Delivery-date: Mon, 14 Mar 2022 08:56:29 +0000
  • Ironport-data: A9a23:p1gAja3lvNSed0hFWvbD5dBxkn2cJEfYwER7XKvMYLTBsI5bpzIOm mAaDTjTPf+DMDb3fYtxOY2z909XuMWGmNNgTQBspC1hF35El5HIVI+TRqvS04J+DSFhoGZPt Zh2hgzodZhsJpPkjk7xdOCn9xGQ7InQLlbGILes1htZGEk1EE/NtTo5w7Rj2tUx3YDga++wk YiaT/P3aQfNNwFcagr424rbwP+4lK2v0N+wlgVWicFj5DcypVFMZH4sDfjZw0/DaptVBoaHq 9Prl9lVyI97EyAFUbtJmp6jGqEDryW70QKm0hK6UID66vROS7BbPg/W+5PwZG8O4whlkeydx /1KjpiiTzcZBJeVwsQ9DzpXUD1zGolvreqvzXiX6aR/zmXDenrohf5vEFs3LcsT/eMf7WNmr KJCbmpXN1ba2rzwkOnTpupE36zPKOHxO4wSoDd4xCzxBvc6W5HTBa7N4Le02R9u2JkQR6yDO 6L1bxJdYQXcaB1XNGsRBbkRpcHrlmvcQgVx/Qf9Sa0fvDGIkV0ZPKLWGMXRUsyHQ4NShEnwj nLL+SH1Dw8XMPSbyCGZ6TS8i+nXhyT5VYkOUrqi+ZZCglee22gSAx0+TkagrL+yjUvWZj5EA xVKoGx09/F0rRH1CImmN/GlnJKalhknX8hWI90A0ljX6oqIwAnaGmUjahcUPbTKq/QKbTAt0 1aImfbgCjpurKCZRBqhy1uEkd+hEXNLdDFfPEfoWSNAuoC++99r0nojW/45SMaIYsvJ9SYcK txghAw3nP0tgMECzM1XFniX0mv39vAlouPYjzg7v15JDCskPuZJhKTysDA3CMqsy67DEjG8U IAswZT20Qz3JcjleNaxaOsMBqq1wP2OLSfRh1Vid7F4qWjyoi/8J9gPv2gmTKuMDirjUWW1C HI/RCsLvMMDVJdURfIfj32N5zQCkvG7SIWNugH8ZdtSeJlhHDJrDwk1DXN8K1vFyRB2+YlmY M/zWZ/1UR4yVPQ2pBLrFrx1+eJ6mUgDKZb7GMmTI+KPiuHFOhZ4iN4tbTOzUwzOxPjd8VuPr IoHaZfiJtc2eLSWXxQ7OLU7dDgiBXM6GYr3u4pQcOuCKRBhA2YvF7naxrZJRmCvt/09ejvgl p1lZnJl9Q==
  • Ironport-hdrordr: A9a23:N4um1KPnRMeWycBcTsWjsMiBIKoaSvp037BN7TEXdfU1SL39qy nKpp8mPHDP5Ar5NEtOpTniAsm9qBHnm6KdiLN5Vd3OYOCMggqVBbAnwYz+wyDxXw3Sn9QtsJ uIqpIOa+EY22IK7/rH3A==
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>

On Mon, Mar 14, 2022 at 09:19:01AM +0100, Jan Beulich wrote:
> On 11.03.2022 15:24, Roger Pau Monné wrote:
> > On Mon, Feb 14, 2022 at 10:25:57AM +0100, Jan Beulich wrote:
> >> Making adjustments to arbitrarily chosen values shouldn't require
> >> auditing the code for possible derived numbers - such a change should
> >> be doable in a single place, having an effect on all code depending on
> >> that choice.
> >>
> >> For one make the TDCR write actually use APIC_DIVISOR. With the
> >> necessary mask constant introduced, also use that in vLAPIC code. While
> >> introducing the constant, drop APIC_TDR_DIV_TMBASE: The bit has been
> >> undefined in halfway recent SDM and PM versions.
> >>
> >> And then introduce a constant tying together the scale used when
> >> converting nanoseconds to bus clocks.
> >>
> >> No functional change intended.
> >>
> >> Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx>
> > 
> > Reviewed-by: Roger Pau Monné <roger.pau@xxxxxxxxxx>
> 
> Thanks.
> 
> >> ---
> >> I thought we have a generic "glue" macro, but I couldn't find one. Hence
> >> I'm (ab)using _AC().
> > 
> > I would be fine if you want to introduce something right in this
> > commit to cover those needs, using _AC is not overly nice (or
> > clear) IMO.
> 
> Hmm, I was rather hoping that you (or someone else) would point me
> at what I thought I'm overlooking. If anything I'd likely clone
> Linux'es __PASTE() (avoiding the leading underscores), but their
> placement in linux/compiler_types.h seems pretty arbitrary and
> hence not a good guideline for placement in our tree. To be honest
> the only thing that would seem halfway consistent to me would be a
> separate header, yet that seems somewhat overkill ... Or wait -
> maybe xen/lib.h could be viewed as kind of suitable. Of course
> there's then the immediate question of whether to make _AC() use
> the new macro instead of open-coding it.

I think if possible _AC should be switched to use the new macro, yes.

Thanks, Roger.



 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.