[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 11:42:28 +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=mPPOEqZJVmC7xgnLNiRIPVUuPOvmYYEnNAeoVmY6X58=; b=EJxV7NRExIpRLkGKgCzp1s6Kz93dJveGvrNOHN0O7Ca26UrHmGChEn+g3Pd+q+fUpsk/GPMmpuEuq1blgFK2R/qpIdUdkTouZymdYhsl2SpiwCo8QV26zPpgZlsTI/Z/5dE4IcMTpn0hO4zbRMb6STWxvGm8Zgo5JY7/Z1niTCFZJL4cb3z2/xbcD9Uc+qHn2I39a25QGp975lYumyroP/5HqxO/i8KKJHkVKTt+IK1/Jr309LdhAD21ZWN8UVqY2mS+JrCb6rZXvip43T0iVWHtzL8joKyQ5PKBlKp74Vm0wQ+OKuryCwCFk47Mlm66AR2HUr5U12pW+7dXjUfYnQ==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=X6xT4PG4krzaZsvwzQc3qS8M/YXUexKmFROFbLScvosSQQutDLMlmpyXTfpjAbrBH1j38TaAIQcG3nuQC5/oVuyv92u/sdXjdWedfVvlCWx0KDIwhMe9cQKdfHDIJ+k0LSPgkYj3OVDuIhMrSTNkQCoN0Yq1f8SfEK3+TYX5799K3c/7xFuuHks5K/+/KikD7d7foLYS4j01iPgjfuVq+xEnR71ddqHbD2gvQA3b+UpV/c+4D6X6Bv1CHyms5ieOpcDJ2MMz4ReM1m6gMCFdy3sBnsk28ZkcI8Uoxh0YhLYPEzkToTM9JTfvCi4qpYoK2VUwtDi8Q2z+sircJ6RbRw==
  • Authentication-results: esa1.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 09:42:50 +0000
  • Ironport-hdrordr: A9a23:bPPnDKHDdlHUMUDWpLqFeZTXdLJzesId70hD6mlYcjYQWtCEls yogfQQ3QL1jjFUY307hdWcIsC7Lk/03aVepa0cJ62rUgWjgmunK4l+8ZDvqgeNJwTXzcQY76 tpdsFFZeHYJURmjMr8/QmzG8shxt7Cy6yzmeLC1R5WLD1CQYsI1XYfNi+wFEpqSA5aQbc4Do Ob/MpbpzymEE5nFPiTLH8DQuTFupn3hIvrCCR2fCIPxSuvqXeT6LD8GwWFxRt2aV1y6Jor7G StqX2a2oyNqPe+oyWsslP7z5MTo9f5z8sGOcrksLlpFhzJqiKFILtsQKeDujddmpDf1H8PnM PXqxkte+RfgkmhB12dmhfm1wn+3DtG0RaLojX58BiT0vDRfz40B9FMgohUaHLimjIdlepxzb 5R2Cahv4dXZCmw4hjV3cTCVB1hiyOP0BwfuNMU5kYvNbc2Wft6qIwS+15tC5EQHC72w5BPKp gQMOjsoNlRal+UdHbfoy1Gx8GtRG06GlO8TlEFodH96UkaoFlJi28jgOAPlHYJ85wwD7FC+u T/K6xt0JVDVNUfY65RDPoIKPHHRlDlcFbpCia/MF7nHKYINzbmsJjs+og44+msZdgh0IYysI 6paiIYiUcCP2bVTeGe1pxC9R7ABE+nWy72981Y759l/pXhWbvQNzGZQlxGqbrvn9wvRungH9 qjMpNfBPHuaUH0H5xS4gH4U55ObVYEVsk4vcs6RkKursrHJpaCjJ2ZTN/jYJ7WVRo0UGL2BX UOGBLpIt9b00ytUnjkxDjdMkmdOHDXzNZVKuz37uITwI8COslnqQ4Ok2m04cmNNHlnuqwyd0 1uHaP/nsqA1CyL1FeNy18sFgtWD05T7rmleWhNvxU2P0T9dqtGnNmDZ2ZI3j+iKgVkR83bVC 5Tzm4Htp6fHti1/2QPGtinOmWVgz84v3SRVaoRnaWF+IPCYZM3DpEvXYRrDgXVHxlJmQJnwV 0zKDMsdwv6LHfDmK+lhJsbCKX0bN9nmjqmJsZStDbir0mGnNouQXEaRjaqdsaSjW8VNn5pr2 w015VarKuLmD6pJ2d6pOgjKlVDZF6aB698AB2faJ9Zna3qfw9MXX6H7Abq+y0bSy7PzQE/l2 bhJSqbdbXwDl1Rtmtx/4zq/Fl3H1/tN35YWzRfi8lQBG7GsnF83au3faK1yXKWcUZH6PoaKi v5bTwbJR5Oy9i72AWOoiuLEWwry/wVT6vgJYVmV4uW9mKmKYWOm61DIuRd+4x9Msvy9sAMSu CSdmauXUTFItJs/zbQgHkrOCN58iZ51dzp3QDo92i+0joUB+HILFFvWrEcJJW94gHfNoO1+a Q8qehwm+26dljVQJqh74r8ajZYMBPdoWKsVYgT2NlplJN3kIE2JoXRVDvD6WpO0xo/JvrljU 92etUI3JnxfqtUO/EIcy1X/lAVhM2CAUsivAvxGPI/dzgW/gvmFuLMx7rDsrw0BEKd4CP2JF mE6iVYls21FBer5Po/C6gqJ35RZ1V5wHN+/Pmaf4mVLAmxbelM8B6bNXC6GYUtApStKPE1rh xg5cuPkPLSXy3k2BrItT8+G5lwyQ+cMLWPKTPJP/VJ/dy8MUmNhaXvwPfbtkaKdRKLL2IChY NEckQMaN9kkTdKtvxw7hSP
  • Ironport-sdr: 7D2X7KVAVIo/0HWB10/Sl8XWYI70rtpG9FASS9TVSbYg1KxfxxY1/lypUXGhtz5rqm1mmPczWc RQ9jFi7Woq3Wd2SaGh5dgS34bT9p7PRLPqPLv+badPCBtcwkkYpIp5jz7bkNVYsfWQ2p84Kccr ldf+lOx+EgTlpKjVW2nvg1xqIygqjU4ohfNJweS79xXjd5Qv+A4zbSdacp8dOsYUjxhDiTH9M9 Mvs+8k+J8HYqOsJh1zS6xSvG05euR2h/P3rMHGBHbbUy0MZpTqFbLUw67CJYAUUbv8B3VC6o+m EGM=
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>

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"

> > +                       xen_cpuid_leaf_t *out)
> > +{
> > +    *out = (xen_cpuid_leaf_t){ };
> > +
> > +    switch ( l1->leaf )
> > +    {
> > +    case 0x1:
> > +    case 0x80000001:
> > +        out->c = l1->c & l2->c;
> > +        out->d = l1->d & l2->d;
> > +        return true;
> > +
> > +    case 0xd:
> > +        if ( l1->subleaf != 1 )
> > +            break;
> > +        out->a = l1->a & l2->a;
> > +        return true;
> 
> Could you explain your thinking behind this (a code comment would
> likely help)? You effectively discard everything except subleaf 1
> by returning false in that case, don't you?

Yes, the intent is to only level the features bitfield found in
subleaf 1.

I was planning for level_leaf so far in this series to deal with the
feature leaves part of the featureset only. I guess you would also
like to leverage other parts of the xstate leaf, like the max_size or
the supported bits in xss_{low,high}?

> > +    case 0x7:
> > +        switch ( l1->subleaf )
> > +        {
> > +        case 0:
> > +            out->b = l1->b & l2->b;
> > +            out->c = l1->c & l2->c;
> > +            out->d = l1->d & l2->d;
> > +            return true;
> > +
> > +        case 1:
> > +            out->a = l1->a & l2->a;
> > +            return true;
> > +        }
> > +        break;
> 
> Can we perhaps assume all subleaves here are going to hold flags,
> and hence and both sides together without regard to what subleaf
> we're actually dealing with (subleaf 1 remaining special as to

I think you meant subleaf 0 EAX (the max subleaf value)?

subleaf 1 EAX is just a normal bitfield AFAIK.

> EAX of course)? This would avoid having to remember to make yet
> another mechanical change when enabling a new subleaf.

Sure, seems like a fine approach since leaf 7 will only contain
feature bitmaps.

> > +    case 0x80000007:
> > +        out->d = l1->d & l2->d;
> > +        return true;
> > +
> > +    case 0x80000008:
> > +        out->b = l1->b & l2->b;
> > +        return true;
> > +    }
> > +
> > +    return false;
> > +}
> 
> Considering your LFENCE-always-serializing patch, I assume
> whichever ends up going in last will take care of adding handling
> of that leaf here?

Indeed.

Thanks, Roger.



 


Rackspace

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