[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH 3/5] x86/perf: expose LBR format in PERF_CAPABILITIES
- To: Andrew Cooper <Andrew.Cooper3@xxxxxxxxxx>
- From: Roger Pau Monné <roger.pau@xxxxxxxxxx>
- Date: Mon, 23 May 2022 10:04:19 +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-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=c6SjOGvFSMVgKXM0stxsmuSoigHb1a+2G+Uj+FzAquo=; b=jzJYWaw7JvhtiFVbab2/9T+aeZbk967m9kCoHVpp8WNY7ABSLaXp225vQnAtD2UdxgaIKZsoEZ5o+yWLpNQ1lTcu2Pbyxmj8c8WDmNqSMPkhbrbRfyY9ek7Vm3qWbsfMXTI6YCQ4Ll7vHOFDuE1AwvsCxfMv3oa+zE+3ubqfKe/rgaqszTYnXfZiERC9wsqpJQzZ0MAYecz8djvd9TpspRdbr0JTDAchUR4yjLpQpt5DVOx6TZsYFIIcTe6cSrdTzWaMFbgUzawN/njGS6GmEfFmaPMwc5F+8PO547L6Vv9VDTeEy68ToFjMI5M7sFSEzP3STK+x8Xq90255wLQCSg==
- Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=hcg6xHSB4j87yFNPbJXKKmIdPrJWYSCnLl70IaBf4koRgv8g9S/yHFz6iQPYj9dPnuyw8WhLabTfITDA+58ljrV3QwbZa8cLLMTekOXTwHL9TKG7Aiy8tsTmemZHOOCcuKTMLYNtezN/ODj1BfCi6ZWeN3D101Omi+0c3wg3vKKvBR9DrtAgMHmhggLr/yeWEAwBrXb/PhxZOacrnq1EfFhp6StgkxybBHLlxUCglI1kTtzOhWIav+NVkCUvzJnjL+5xyD8DiwPrb79twzHj437EZtdHTJ57kGIvT/MNM93wZjGq+zVTgYUa4NTEX3AX8RFPQLDMGQM54ZSscULdlw==
- Authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=citrix.com;
- Cc: Jan Beulich <jbeulich@xxxxxxxx>, Wei Liu <wl@xxxxxxx>, "xen-devel@xxxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxxx>
- Delivery-date: Mon, 23 May 2022 08:04:36 +0000
- Ironport-data: A9a23:7MKeJ644Pf9xA9yDQuglpgxRtEzGchMFZxGqfqrLsTDasY5as4F+v mQWDT+GOayMMGOkKdEjYIu38kJTsJbXx9JnGVRo/y8yHi5G8cbLO4+Ufxz6V8+wwmwvb67FA +E2MISowBUcFyeEzvuVGuG96yE6j8lkf5KkYAL+EnkZqTRMFWFw0HqPp8Zj2tQy2YXjWFvU0 T/Pi5a31GGNimYc3l08s8pvmDs31BglkGpF1rCWTakjUG72zxH5PrpGTU2CByKQrr1vNvy7X 47+IISRpQs1yfuP5uSNyd4XemVSKlLb0JPnZnB+A8BOiTAazsA+PzpS2FPxpi67hh3Q9+2dx umhurSxFxkbYpaQnt1BeAZ3M3FFA5Fo+6PYdC3XXcy7lyUqclPK6tA3VAQcG9Jd/ex6R2ZT6 fYfNTYBKAiZgP67y666Te8qgdk/KM7sP8UUvXQIITPxVK56B8ycBfqSo4YAh1/chegXdRraT 9AeZjd1KgzJfjVEO0sNCYJ4l+Ct7pX6W2IC8wjM/fpti4TV5CFSjZLAFOiSQcyHFNsNlX6lr 3La202sV3n2M/Tak1Jp6EmEhOXCgCf6U4I6D6Cj+7hhh1j77nMXIA0bUx28u/bRol6zXZdTJ lIZ/gIqrLMu7wq7Q9/lRRq6rXWY+BkGVLJt//YS7QiMzu/e5VmfD21dFjpZMoV+74kxWCAg0 UKPk5XxHztzvbaJSHWbsLCJsTe1PitTJmgHDcMZcTY4DxDYiNlbpnryohxLSsZZUvWd9enM/ g23
- Ironport-hdrordr: A9a23:CZRxhq58s7wIf4WkwAPXwVqBI+orL9Y04lQ7vn2ZFiY5TiXIra qTdaogviMc6Ax/ZJjvo6HkBEClewKlyXcT2/hrAV7CZniehILMFu1fBOTZowEIdxeOldK1kJ 0QCZSWa+eAcmSS7/yKhzVQeuxIqLfnzEnrv5a5854Ed3AXV0gK1XYcNu/0KDwVeOEQbqBJaa Z0q/A37gaISDAyVICWF3MFV+/Mq5nik4/nWwcPA1oC5BOVhT2lxbbmG1zAty1uGA9n8PMHyy zoggb57qKsv7WSzQLd7Xba69BzlMH6wtVOKcSQgow+KynqiCyveIN9Mofy9AwdkaWK0hIHgd PMqxAvM4Ba7G7QRHi8pV/X1wzpwF8Vmgvf4G7dpUGmjd3yRTo8BcYEr5leaAHl500pu8w5+L 5X3kqC3qAnQi/orWDY3ZzlRhtqnk27rT4JiugIlUFSVoMYdft4sZEfxkVIC50NdRiKpLzPKN MeTf002cwmMW9zNxvizypSKZ2XLzkO9y69MwY/Upf/6UkVoJh7p3FosfD30E1wsa7VcKM0lt gsAp4Y6o2mcfVmHZ6VJN1xNvdfWVa9Ny4lDgqpUCfaPZBCHU7xgLjKx5hwzN2WWfUzvekPcd L6IRlliVI=
- List-id: Xen developer discussion <xen-devel.lists.xenproject.org>
On Fri, May 20, 2022 at 02:58:01PM +0000, Andrew Cooper wrote:
> On 20/05/2022 15:19, Jan Beulich wrote:
> > On 20.05.2022 16:10, Andrew Cooper wrote:
> >> On 20/05/2022 14:37, Roger Pau Monne wrote:
> >>> --- a/xen/include/public/arch-x86/cpufeatureset.h
> >>> +++ b/xen/include/public/arch-x86/cpufeatureset.h
> >>> @@ -135,7 +135,7 @@ XEN_CPUFEATURE(SSSE3, 1*32+ 9) /*A
> >>> Supplemental Streaming SIMD Extensio
> >>> XEN_CPUFEATURE(FMA, 1*32+12) /*A Fused Multiply Add */
> >>> XEN_CPUFEATURE(CX16, 1*32+13) /*A CMPXCHG16B */
> >>> XEN_CPUFEATURE(XTPR, 1*32+14) /* Send Task Priority Messages
> >>> */
> >>> -XEN_CPUFEATURE(PDCM, 1*32+15) /* Perf/Debug Capability MSR */
> >>> +XEN_CPUFEATURE(PDCM, 1*32+15) /*S Perf/Debug Capability MSR */
> >> This is the bit which requires more toolstack logic to safely enable.
> >> Using 's' for off-by-default is fine if we want to get the series in now.
> >>
> >> But before we expose the MSR generally, we need to:
> >>
> >> 1) Put the configuration in msr_policy so the toolstack can reason about it
> >> 2) Reject migration attempts to destinations where the LBR format changes
> > Since this could be quite restrictive, and since people needing to know
> > they need to hide this feature for migration to work, I guess this would
> > further want qualifying by "did the guest actually use LBRs so far"?
>
> In practice, it's every major generation ("tock" on Intel's old model),
> so isn't actually limiting the kinds of heterogeneous setups used in
> production. (Migration gets steadily less stable the further apart the
> two CPUs are.)
>
> As to dynamic, no - that would be a security bug in a cloud scenario,
> because there must not be anything the guest can do to interfere with
> the manageability.
>
> Use of LBR is rare, as demonstrated by the fact that noone has
> complained about the fact that migrating such a VM will malfunction.
>
> As we now have a way of reporting "no model-specific LBR", I'm tempted
> to suggest that VMs get no LBR by default, and someone wanting LBR has
> to opt in, which is also an explicit agreement to the migration limitation.
I did also consider exposing "no model-specific LBR" in
PERF_CAPABILITIES unconditionally, but I was worried whether that
would break existing setups.
If we think that providing an option to expose the native LBR format
in PERF_CAPABILITIES is fine that could be a sensible solution IMO.
Thanks, Roger.
|
