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

Re: [PATCH] libs/guest: Don't hide the indirection on xc_cpu_policy_t


  • To: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
  • From: Roger Pau Monné <roger.pau@xxxxxxxxxx>
  • Date: Wed, 5 May 2021 11:16:08 +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=wKHhj6j9usx28MOesGH7ZYw6c5IjxCdUm47/6L3H3Bc=; b=D+G56WWaYtZS4avfJGrd16ddOrQkkN1INzmXMG4F3DrCFUbFvJsfiJRc925WtSZbVYo5LpspL2SdCH0WA8J3gTeQ7vvFVj1XfUmIMzARg434lSCfodnsi5aKx3TJp9GWV1tLh4MEkzsbiX3kqHmZ16qicQRJ8B7uDkbruWd1t+wQYj6LctuinbBXRVwZl5S3cTCHycnvMZmOY0HN0anq4c7F5aXZut7liF6BEwQVNv68kzETESd2Zu8Mmnr7WQcD9KBqCHH39PCoSOkQkNuW5YRuDcIOlxmHRffhVhNYLn0gx/Y4hObX8D66uvbvm6+7adwJuZZZMvyanFZn3n4EVA==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=UBepOm+DekX9tVmLPZIw/855zo9N3extc8/fI9wYDa7jul45Fgl7+o0Htt4FeQBCHRygW3+od1CY9yXT1WC6tXz7B+e14US3w5fBgpU9Y4m/emS/eMa3WFSOOOQ0xqK84TAZG9RFiGUQetG6tsZWhRmoaNUQMMvfLhonuYt+DMhkV48HebMxk8v0LhmY6ECO67L8Kw33Wp0tNqjFNrIsYQ1DjrpDI2e1sd4y1pZR26LNiv006vsGWSQ1LU0VwfUGHQeDkHuq6E9clZBsYFUo3HU/iuG8N/R49E8S9VtXunzb8OP1StlpHu34gB6fbb8U7iPwkvTZ61fFa4wI/kwgmQ==
  • Authentication-results: esa5.hc3370-68.iphmx.com; dkim=pass (signature verified) header.i=@citrix.onmicrosoft.com
  • Cc: Xen-devel <xen-devel@xxxxxxxxxxxxxxxxxxxx>, Jan Beulich <JBeulich@xxxxxxxx>, Wei Liu <wl@xxxxxxx>
  • Delivery-date: Wed, 05 May 2021 09:16:28 +0000
  • Ironport-hdrordr: A9a23:nULHL6GEWUXqdQwKpLqFWJTXdLJzesId70hD6mlYcjYQWtCEls yogfQQ3QL1jjFUY307hdWcIsC7Lk/03aVepa0cJ62rUgWjgmunK4l+8ZDvqgeNJwTXzcQY76 tpdsFFZeHYJURmjMr8/QmzG8shxt7Cy6yzmeLC1R5WLD1CQYsI1XYfNi+wFEpqSA5aQbc4Do Ob/MpbpzymEE5nFPiTLH8DQuTFupn3j5rgexELHFoK7wOJgDOu5tfBYmWl9z0ZVC5CxqpnzH jdn2XCl96emtyY6juZ7W/c6JxKhMDso+EsOOWggtUYQw+c6DqAS59mX9S5zVUIicGprG0nid zd5yonVv4Dl0/5WkGQjV/T1xL70DAogkWSuWOwpXf4u8T2SHYbJqN69PtkWyDU4UYho91wuZ gjtwny1+s1fGH9tR/w6NTSWxZhmlDcmwtbrccpg2FCSoxbUbdNrOUkjTJoOa0dFyH34p1PKp gJMOjg4p9tADenRkGclGxuzNuwZ280DxeLT2MT0/blrQR+rTRXyVAVy9cYmWpF3JUhS4Nc7+ CBCahwkqpSJ/VmIZ5VNaMke4+aG2bNSRXDPCa7JknmLrgOPzbop4Ts6Ls4yem2cPUzvdQPsa WEdGkdmX85ekroB8HL9oZM6ArxTGK0Wimo4t1C5rBi04eMBIbDAGmmchQDgsGgq/IQDonwQP CoIq9bBPflMC/HBZtJ5QvjQJNfQENuEfE9i5IeYRajs8jLIorluqjwa/DIPofgFj4iRyfRGX 0GcD/vJNhRz0yiV3Pi6SKhGU/FSwjax9ZdAaLa9+8cxMwmLYtXqDUYjly/+4WqJFR5w+kLVX o7BImivrKwpGGw82qNxX5uIABhAkFc56ild3tLoAQNIn7laLprgaTaRUlimF+8YjNvRcLfFw BS435t/7isEpCWzSc+T/WqL3ydlHlWgH6RVZ8Tlumi6K7eC90FJ6djfJY0ORTAFhRzlwovgn xEchU4SkjWES6rr76kgpwSDOT2bMJ9nw+vHM5RpRvkxAahjPBqYkFecy+lUMaRjwprbSFTnE dN/6gWh6fFpSyiMlIlgOMzMERFbUOeBL4uNnXDWKxk3pTQPC1gR2aDgjKXzzU+YHDj+Ukpim v9FiGMYv3QDl1BundX77by/DpPBxagVnM1Tko/nZx2FGzAtHo26+ONa6ap+0a6a1cJwIgmQX r4SApXBjkr68G81RaTljrHKG4vwY82OPfBSJ45davI53+rIIqUtK0PEvNO5qx5PNT2vuJja5 PYRyalaBfDT8850Q2coXgofBRuoH4/iPXyxVnL6nO70HNXO4ulHH1WA5UgZ/eS4GjvS6zWjN FXjdcpsfCxNWu0QNic0q3TZyNCLBSWgWPedZBdlblk+YYJ8J10FN3ndBGN8ldt9hA3Nt31m0 MTW74T2sGIBqZfO+gpPxtE9V8onumVJEQlsgbKEvYzFGtd+kPzDpes2f70srIhDU2KmRvoNX Se+yNb+e3ZXyHr789sN4sAZUBXYlM78nJs4aercJDREhyjc4h4jRCHG074VL9WU66eH7oM6j 58/tGThueSMw71whrZszc+AqVA9Q+cMI6PKTPJPe5D6NqhP1uQxoOs/c6olT/yDQKBVH5wv/ wNSWUgKuJZijcji4Ur0i+9DozPy3hV7Gd20HVAjV7i2o+v/WHBO1pJWDep26lrYQ==
  • Ironport-sdr: iP/ZWPTKv0jJrjmGJ+n5zNfk7QT56JvPS+jm3LnlTic9CT7JbdEEg+S7MOA9CSckSbmTIWb6Fs H9SpHTBy0LW0nE3azCaAgL3mWKA6aRoSMfhG5NFu/OhKfaZRhaVs7xLzqkEMkJ7h0a3g+KWgdw th3166COomKVzGodGkVQ1sBvZQfibPQTuujuzhhp8VxypAT6Z7BAYd8lban/XtGkhScyPV6GOq 0rgkMRW//T+4sRG/Jd6lnjMQ5L/3Vmqy1RgsVZ8y99g+SkBCo4n7h2mw/c24zPw+u9C4hcyfhh 7Fc=
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>

On Tue, May 04, 2021 at 07:53:22PM +0100, Andrew Cooper wrote:
> It is bad form in C, perhaps best demonstrated by trying to read
> xc_cpu_policy_destroy(), and causes const qualification to have
> less-than-obvious behaviour (the hidden pointer becomes const, not the thing
> it points at).

Would this also affect cpuid_leaf_buffer_t and msr_entry_buffer_t
which hide an array behind a typedef?

> xc_cpu_policy_set_domain() needs to drop its (now normal) const qualification,
> as the policy object is modified by the serialisation operation.
> 
> This also shows up a problem with the x86_cpu_policies_are_compatible(), where
> the intermediate pointers are non-const.
> 
> Signed-off-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>

Acked-by: Roger Pau Monné <roger.pau@xxxxxxxxxx>

> ---
> CC: Jan Beulich <JBeulich@xxxxxxxx>
> CC: Roger Pau Monné <roger.pau@xxxxxxxxxx>
> CC: Wei Liu <wl@xxxxxxx>
> 
> Discovered while trying to start the integration into XenServer.  This wants
> fixing ASAP, before futher uses get added.
> 
> Unsure what to do about x86_cpu_policies_are_compatible().  It would be nice
> to have xc_cpu_policy_is_compatible() sensibly const'd, but maybe that means
> we need a struct const_cpu_policy and that smells like it is spiralling out of
> control.

Not sure TBH, I cannot think of any alternative right now, but
introducing a const_cpu_policy feels kind of code duplication.

Thanks, Roger.



 


Rackspace

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