[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.



 


Rackspace

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