[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH v2 15/21] libs/guest: obtain a compatible cpu policy from two input ones
- To: Jan Beulich <jbeulich@xxxxxxxx>
- From: Roger Pau Monné <roger.pau@xxxxxxxxxx>
- Date: Thu, 22 Apr 2021 12:56:18 +0200
- 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-SenderADCheck; bh=b605RN8JIIFLEBxtm9Y/iFQiowI32YEdALrDHV9GPSY=; b=afcOc4Ui8L22mOUWf7Tbjh7zjVox+wOtXPqDirmMmiXGv0X9h+yOC8PpDomqgZqN18nB7HpLla9FApvv0G6VBVmWfkGpWSb7qg/USFN1WPBjNod8Jdsa42+/7td+WdRxX/zYUBfUZTT1RV+vC6tCv7OhEEz3eeHiH38iiQ38gapWSoE6OBowi+/yOr8RT+4DrMYhwpJ1j6Dg+sYqJ7CNh2Br6U2vx1524kooT3qVzShTqf/q3r4u2vZNTw0M24j1RkHfYCDxA2+FJ6cS3iaTBm2QBQA2/2fL+nWs4AaqS/XR0G6V4N6wbnhf57y7xlHK1+wz4dhFYdg0THKMQKyNvg==
- Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=XILLV7JXe+BqA38Y1+30WmOhh9sFlQii+QvtAOnw5PAJzFJzlEpkbtbchD7y5w8Da+PffvtEJ8fs0sgoD/CxphCRDijixqsVSqGhsUkf7Ccw3qLHIaaY19bbzNlrldig7z11rbM65pkfeja/orgIFpq+wWPFGR8GfgruZUMCpPs+mLV/RZHKhHRuop3/N5WqCIup9U/uAN/398/DvWaqWIM7AWyWNKM8aV7tTq4P3EJ5likRvYgfVuwaO+bpFSZ1XjIQj3AjqNi8nn9LtdaA4DBjXee/15rS3grkVWACcnHW7cRX9Xb2hc6N6NfgiFTm0znMLZ0hYDdZ2N4A5y9SgA==
- Authentication-results: esa3.hc3370-68.iphmx.com; dkim=pass (signature verified) header.i=@citrix.onmicrosoft.com
- Cc: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>, Ian Jackson <iwj@xxxxxxxxxxxxxx>, Wei Liu <wl@xxxxxxx>, Anthony PERARD <anthony.perard@xxxxxxxxxx>, <xen-devel@xxxxxxxxxxxxxxxxxxxx>
- Delivery-date: Thu, 22 Apr 2021 10:56:38 +0000
- Ironport-hdrordr: A9a23:nzI1HK7VdgDdRouBLAPXwXqEI+orLtY04lQ7vn1ZYSd+NuSFis Gjm+ka3xfoiDAXHEotg8yEJbPoex3h3LZPy800Ma25VAfr/FGpIoZr8Jf4z1TbdBHW3tV2kZ 1te60WMrHNJHBnkMf35xS5Gd48wN+BtJuln/va0m0Fd2FXQotLhj0JbDqzOEtwWQVAGN4VFI CE4NBGujqnfh0sH7mGL1MCWPXOoMCOqYnvZgQICwVixA6Fiz6p77CSKWnl4j41VTRTzbA+tV XUigCR3NTYj9iX6D/5k1XS4ZNfhcf7xrJ4ZfCkp8AJJlzX+2OVTat7XbnqhkFQnMiO7xIQnM DIs1McOa1ImgzsV0WUhTeo5AX6yjYp7BbZuCylqF/uu9bwSj5/K+cpv/MgTjLj50AtvM5x3c twtgrz3fcnbmKj7VHAzuPFWB1wmk2/rWBKq59ps1VlXZYDc7gUlIQD/SpuYec9NRjn44MqGv QGNrCk2N9qdzqhHhfkl1gq6tmtUnMvJwyBU0gPt+eEugIm7UxR/g82wtcSkWwH8494Y55Y5/ 7cOqAtr71WSNQKBJgNS9spcI+SMCjgUBjMOGWdLRDOE7wGAWvEr9rS7K8u7O+nVZQUxPIJ6d r8eWIdkVR3V1PlCMWI0pEO2AvKWn+BUTPkzdwbz4Rlu5XnLYCbchGreRQLqY+Nsv8fCsrUV7 KYI5RNGcLuKmPoBMJgwxD+YZ9PMnMTOfdl+uoTaharmIbmO4fqvuvUfLL4P7z2CwspXWv5Hz 8tRz72CMJc7l26e3PxjRTLMkmdP3DXzNZVKuz37uITwI8COslnqQ4Ok2m04cmNNHljv8UNDQ 9DCYKitpn+iXi9/G7O4WksEAFaFFxp7LLpVG4PgQcLNkjzYIsSotn3QxEU4FK3YjtEC+/GGg 9WoFp6vYitKYaL+CwkA9W7dkWXkmUUv3DPa5sHgKWM6YPEd/oDf9cbcZ00MT+OOw1+mA5spm sGQhQDXFXjGjTnjrjgqocVCuHZf9xVmxyqPsZQlHLauSyn1IMSb0peewTrfd+cgA4oSTYRrE Z26bUjjL2JnivqFXEym90iMFpHaH2eBZVPCAjtXvQTppnbPCVLCUuajz2TjB8+Pk7n7V8biG DaISqIQv3TGVZGtndE0qHlzUNsegymDjBNQ0E/lbc4OXXNu3513+POXKa13meLQnYpw+0WMl j+EHEvCzIr4+ry+A+emT6EG3lj+44nOfbFCq8/N5vJ3Gm2FYGOnaYaPvNd8Zp/LuryuusTXe /3QX7NEBrIT8cSnyCFrHcsPyd57EQ+mfTzwRv/8SyW2mU8Dfe6GiUue5grZ/Wnq07qSPaD3M 8n0ZYbve6sPn7wbdDD46fNdDJHIg7Sp2nzb+xAk+EigYsC8J9IW7/cWn/08VsC+jMUBsL9jl kfT6R2+6qpAP4lQ+UiPwZiumM0n9GOJnYxugP4AuUCbUgg5kWrS++h0v7tk/4TGUWPqwv7BE mH/wBc9/nDWTGf1bRyMdNHHU1mLGw94m9l5uWMasn5DxirbfhK+DOBQzKAWY4YbKiOArMLqB lmp/mOgu+MbiL9nCTdpyFyLK4L02GpR6qJcU6xMN8N19yxIlKXhKS2pOa1kTfsUDO+L30iur ctTz1ZUu1zzh84jIM21SCuSqv45mId+mEunw1PpxrKwYip4GDSAEdcFxbW668mBQVuDg==
- Ironport-sdr: +pybSbNFVq13Z8U8rb9yqsOA01kn8sfMXu71gH2ywU08PBfZsOyeF4Dh3zpPAoubXsnvM4Hqip 1Bb8bfa86TndogkzKaDl9sKe3lR5d6TgbWKOLBSLMvu2j8hbJHJa4eqxtYV3L/vRIooFVPZDVp nyJJWjFJVkKAGE6IzSF/eXjUA0KxOODzEjdyRcYzRkxwIEhSMwJFrQJ2zoceIXi0Yo/Uvx80Jz wVJulUwIpoixFhLECWBLj458Jia+gcIFNIfHVGrWk26CP2TQFx0APMyFjMADp0VcFrhYJYa6E9 YVQ=
- List-id: Xen developer discussion <xen-devel.lists.xenproject.org>
On Thu, Apr 22, 2021 at 12:48:36PM +0200, Jan Beulich wrote:
> On 22.04.2021 12:34, Roger Pau Monné wrote:
> > On Thu, Apr 22, 2021 at 11:58:45AM +0200, Jan Beulich wrote:
> >> On 22.04.2021 11:42, Roger Pau Monné wrote:
> >>> On Wed, Apr 14, 2021 at 03:49:02PM +0200, Jan Beulich wrote:
> >>>> On 13.04.2021 16:01, Roger Pau Monne wrote:
> >>>>> @@ -944,3 +945,130 @@ bool xc_cpu_policy_is_compatible(xc_interface
> >>>>> *xch, const xc_cpu_policy_t host,
> >>>>>
> >>>>> return false;
> >>>>> }
> >>>>> +
> >>>>> +static uint64_t level_msr(unsigned int index, uint64_t val1, uint64_t
> >>>>> val2)
> >>>>> +{
> >>>>> + uint64_t val = val1 & val2;;
> >>>>
> >>>> For arbitrary MSRs this isn't going to do any good. If only very
> >>>> specific MSRs are assumed to make it here, I think this wants
> >>>> commenting on.
> >>>
> >>> I've added: "MSRs passed to level_msr are expected to be bitmaps of
> >>> features"
> >>
> >> How does such a comment help? I.e. how does the caller tell which MSRs
> >> to pass here and which to deal with anyother way?
> >
> > All MSRs should be passed to level_msr, but it's handling logic would
> > need to be expanded to support MSRs that are not feature bitmaps.
> >
> > It might be best to restore the previous switch and handle each MSR
> > specifically?
>
> I think so, yes. We need to be very careful with what a possible
> default case does there, though.
Maybe it would be better to handle level_msr in a way similar to
level_leaf: return true/false to notice whether the MSR should be
added to the resulting compatible policy?
And then make the default case in level_msr just return false in order
to prevent adding MSRs not properly leveled to the policy?
Thanks, Roger.
|