[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: Jan Beulich <jbeulich@xxxxxxxx>
  • From: Roger Pau Monné <roger.pau@xxxxxxxxxx>
  • Date: Mon, 23 May 2022 11:53:12 +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=hueTV5O0UHuRLSL6GaRN1R2ZatIg17psVt+HIchGY4o=; b=iyf3Wk7xzIZrpc94ooDkzsJX/lv14rVhRaW3DqDOI9NG25Gf/zLtukVkMc1GZ/jiocUMeD1AdGPP7/vLQg0Q/Rn1AvZKZh0ONeOB04LSawi2gj834GBYhXXma1EiS51fJ0HB1PJXIIcnnniUYHqpiyEChlPKnIsMALUAzB2piX6wHe5aB49Ky9+NX9S/NUM6NkckAZgxlLhvBcW/aLk5A2VM9hB6lALD7sGTTw7UHiM9Oy07U4Tf6K8HjwGzOtlFFKtIJEYAQ5ud2qMe4thTSH2n8Y3NYRgDqMILzNBANWFqewFWfR1rNNbRfuBgw/jpAnt4fiwi5n6Rc0Xlr206vw==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=ZjDdiOc5XEQUztzyNF5Udn2UEgguxaPPh5RCX1CZNUROory2xNdP98RzlAZyUbWy6sDvg/4pymkQ6n73t9XzT1g+mJypnqrSxHwGiLlElQcWSPN1/nMP+wZBRgoWeKxMFoVpcZRhovIFLV66Y3N8wbCOAwA7WzJ51qUDPh/hw7a+n943SSECdOvkivgmCOdaltSgG/PXMkczEnsRVVhiQjFdGmlAGGi9r7mYJGGR7erhfwdt9yVObqwHR1Be99cH8usjcNAw9RqhAQ8h9bZ0EdN3SBDXOBv9E8Zal3IiGqChI3QKMZ0jyefWqZ7v32dXU9MXPfjkbcH70zacm/thcg==
  • Authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=citrix.com;
  • Cc: Andrew Cooper <Andrew.Cooper3@xxxxxxxxxx>, Wei Liu <wl@xxxxxxx>, "xen-devel@xxxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxxx>
  • Delivery-date: Mon, 23 May 2022 10:01:39 +0000
  • Ironport-data: A9a23:ohoxMKOGqBtUWGnvrR3RlsFynXyQoLVcMsEvi/4bfWQNrUp0hjQEz zNLXmuCPP+JZ2L9e9x+Pd/ioUIBvMCDn9VmSAto+SlhQUwRpJueD7x1DKtR0wB+jCHnZBg6h ynLQoCYdKjYdleF+lH1dOKJQUBUjclkfJKlYAL/En03FFYMpBsJ00o5wbZk2NUw2LBVPivW0 T/Mi5yHULOa82Yc3lI8s8pvfzs24ZweEBtB1rAPTagjUG32zhH5P7pGTU2FFFPqQ5E8IwKPb 72rIIdVXI/u10xF5tuNyt4Xe6CRK1LYFVDmZnF+A8BOjvXez8CbP2lS2Pc0MC9qZzu1c99Z5 Y1nt5OsdFwQMoboyMg5XjNXSBgkIvgTkFPHCSDXXc276WTjKyep5so0SUY8MMsf5/p9BnxI+ boAMjcRYxufhuWwhrWmVu1rgcdlJ87uVG8dkig4kXeFUrB5GtaaHPiiCdxwhV/cguhUGvnTf YwBYCdHZxXceRxffFwQDfrSmc/33yilLmID8Dp5o4ILszHOxU900IPoPeDPOfCaYP1aglyx8 zeuE2PRR0ty2Mak4TiP/2+oh+TPtTjmQ49UH7q9ntZ1hHWDy2pVDwcZPXOrrP/8hkOgVtZ3L 00P5jFovaU07FasTNT2Q1u/unHsg/IHc99ZEul/7R7XzKPRu1adHjJdEWMHb8E6vsgrQzBsz kWOg97iGT1otvuSVG6Z8bCX6zi1PED5MFM/WMPNdiNdi/GLnW35pkunogpLeEJtsuDIJA==
  • Ironport-hdrordr: A9a23:mrUe5KrEpawGKvaUKnfAzS4aV5oleYIsimQD101hICG8cqSj9v xG+85rsyMc6QxhP03I9urwW5VoLUmyyXcX2/h0AV7BZniFhILAFugLhuGOrwEIcxeOj9K1vp 0BT0ERMrPN5CBB/KPH3DU=
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>

On Mon, May 23, 2022 at 10:12:55AM +0200, Jan Beulich wrote:
> On 20.05.2022 16:58, 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",
> 
> Which only rather new guest kernels will know to look for. Hence ...
> 
> > 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.
> 
> ... while in principle I agree with this, I see a practical issue.

I think it should be fine to expose no model-specific LBR support in
PERF_CAPABILITIES, but we shouldn't change the behavior of
DEBUGCTLMSR.LBR exposed to guests if the underlying platform has
model-specific LBRs and those are known to Xen.

That way old guest kernels that ignore PERF_CAPABILITIES.LBR_FORMAT
will continue to work, while newish kernels that check the format will
avoid using LBRs.

In case we introduce a guest config option to enable LBR, should we
then expose the native LBR format in PERF_CAPABILITIES?  Or would it
be better to just keep the current model and not expose
PERF_CAPABILITIES at all (and don't report PDCM in CPUID in that
case).

Thanks, Roger.



 


Rackspace

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