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

Re: [PATCH v3 03/22] x86/xstate: re-size save area when CPUID policy changes


  • To: Jan Beulich <jbeulich@xxxxxxxx>
  • From: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
  • Date: Tue, 11 May 2021 17:41:54 +0100
  • 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=J34mvslvyE2BkQ5cxj3q/tvzkRJ4tyApqnGhdsNAF4Q=; b=fu3M7EJguc1+X7hCpi0s/nPF4wINxDM87NNeigH74whNBZ5/OhuG0azDF8o6ibl+9DOs6m8vxkdF/FqoViabnaKRxn5mlJY4ab8laZDSJkZQA56/V7FdKsVzuVG4qIERR24eEOoH+2NkXjcbDy1ps1IXsP9NrN+0xGu1LObG3yvtBh4Eyshv0gTxsf3dlXsFpxyWPUyb14U4O6ChlM1EbgZCILyTwh8YnQaBWmKA6jIhM8uN5AdgxVjB3MJYbuhwmTeCVNyfQ1bWaDtOHZyfAB0arcbK4fzA29EbbuU8yJCy/X22whopBr0uE+eCrDSW3BckVpIRnPkGKR7OaBY+zg==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=PNlbpEYNq+rAjKMCq+smjMd8B29YnWxAgqbQU3wKlMrJHAdBvkY1U+p61edCY50C8FSubAS6CwY96xyeQirdX46R9q9oSdOYPqDB7KrPODzsxLhxDmzbsMBWLMjWTgVLJRrzOH0489FlWvtSF93EoJ/UWCQJ0ZIjzI3dLQ5x3NHWDWX0K0MEQG3IuFxNiQbBNCUIg9Kk270ALARyY1HG4HFslnX1kzVxbeLanZefjOBSvzaljotChbXfYmciuIbGlt8hDSctC9aHYCC9mM7Qb0dMb84aHKKXoIcjI1kffLMI6dCn9yUpU8Ds9XvUh7RNC27NyfnCbVSAS2FVGloOqw==
  • Authentication-results: esa6.hc3370-68.iphmx.com; dkim=pass (signature verified) header.i=@citrix.onmicrosoft.com
  • Cc: George Dunlap <george.dunlap@xxxxxxxxxx>, Ian Jackson <iwj@xxxxxxxxxxxxxx>, Julien Grall <julien@xxxxxxx>, Stefano Stabellini <sstabellini@xxxxxxxxxx>, Wei Liu <wl@xxxxxxx>, Roger Pau Monné <roger.pau@xxxxxxxxxx>, "xen-devel@xxxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxxx>
  • Delivery-date: Tue, 11 May 2021 16:42:24 +0000
  • Ironport-hdrordr: A9a23:uC2XXqh1J0EeZJod35JZP/AJ0nBQXh4ji2hC6mlwRA09TyX5ra 2TdZUgpHrJYVMqMk3I9uruBEDtex3hHP1OkOss1NWZPDUO0VHARO1fBOPZqAEIcBeOldK1u5 0AT0B/YueAd2STj6zBkXSF+wBL+qj6zEiq792usEuEVWtRGsVdB58SMHfiLqVxLjM2YqYRJd 6nyedsgSGvQngTZtTTPAh/YwCSz+e78q4PeHQ9dmca1DU=
  • Ironport-sdr: LsL6Xre9yOcBUpJlBxEOY4eXtl+UUyTpxDAyLpN8uRdntYUqWlHKLe8nn6F+CN2eBiN9rSr42a ERDqUtwX9AB1xaAxYFARXOSK4c4JFXmH/dnwWV2iTnyz4katlLAkyCLo3yoA9K6L9ArT+Rd1RT 1Bu9+kzu88eeIVYZxgAcqKrFilYpPAvOUhpziLocRPQCygOWf6HChMskR463KNj468sFrMP3cg 5yA8gSuZG7qM70lmF+l5+4A+L65BGyqxFqr+cy/OEn01964nZWEGmVmXddFTqg0khV27EBPeFo STQ=
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>

On 03/05/2021 15:22, Jan Beulich wrote:
>> Another consequence is that we need to rethink our hypercall behaviour. 
>> There is no such thing as supervisor states in an uncompressed XSAVE
>> image, which means we can't continue with that being the ABI.
> I don't think the hypercall input / output blob needs to follow any
> specific hardware layout.

Currently, the blob is { xcr0, xcr0_accum, uncompressed image }.

As we haven't supported any compressed states yet, we are at liberty to
create a forward compatible change by logically s/xcr0/xstate/ and
permitting an uncompressed image.

Irritatingly, we have xcr0=0 as a permitted state and out in the field,
for "no xsave state".  This contributes a substantial quantity of
complexity in our xstate logic, and invalidates the easy fix I had for
not letting the HVM initpath explode.

The first task is to untangle the non-architectural xcr0=0 case, and to
support compressed images.  Size parsing needs to be split into two, as
for compressed images, we need to consume XSTATE_BV and XCOMP_BV to
cross-check the size.

I think we also want a rule that Xen will always send compressed if it
is using XSAVES (/XSAVEC in the interim?)  We do not want to be working
with uncompressed images at all, now that MPX is a reasonable sized hole
in the middle.

Cleaning this up will then unblock v2 of the existing xstate cleanup
series I posted.

>> In terms of actual context switching, we want to be using XSAVES/XRSTORS
>> whenever it is available, even if we're not using supervisor states. 
>> XSAVES has both the inuse and modified optimisations, without the broken
>> consequence of XSAVEOPT (which is firmly in the "don't ever use this"
>> bucket now).
> The XSAVEOPT anomaly is affecting user mode only, isn't it? Or are
> you talking of something I have forgot about?

It's not safe to use at all in L1 xen, because the tracking leaks
between non-root contexts.  I can't remember if there are further
problems for an L0 xen, but I have a nagging feeling that there is.

~Andrew




 


Rackspace

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