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

Re: [PATCH 3/5] x86/xstate: Rework xstate_ctxt_size() as xstate_uncompressed_size()


  • To: Xen-devel <xen-devel@xxxxxxxxxxxxxxxxxxxx>
  • From: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
  • Date: Mon, 3 May 2021 19:17:48 +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=BMVq/PVM5fTVIL1pWHdqj1g4J5WYn+Z6zPmOXnMPNjU=; b=mbMbOwjHtyz5Cv0+y2fs6P9eUYiZ9CLXI3k/ehYKAHJ6OD4N+VHLy/3QwR83YvmYSqXNOgAKko5q5iebxjFqRdFu3aDYxC8MRnMpNkgfxBYqct80SbGsZIB0bsGRRIpqwM3izplnmfer+b7aSBP9KWYXK7A+VNOaWYEKEDJZ4zUdD4XZ+YKg9mgKf71+0rVWcQ+cJpgZQaFMkvXMRpL6cfO/YdE2vuBQsYJZDs7W/VpjVIewjCPFEmvPi/viu7SxC5o+WvmeFKSYY6XuvmJrTrHzgCNNL1l9vXhnenYHplYArrWcm5NuSC+ayxCfJ1MTG1zsYv+qSRIzG8Ge1jlqyw==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=fgQJkSFhDjRWN1m7olL8ZD2sNIukdQrBm8I6zZfCjq0ofZ4sEF3bwgUEX39h3H9Vy9Q8ghjO4wQ46wohCk/B6WYLiiHU4ZuNiThtrpcfqr+rmkYYjA83CVtNZ+TPO/a3eQ3Kg+IFWL8Esth0gFTZ3Kgkqxjl0RbTM5LJhJDnZJP0FYa6RtxKixULQ3htKXtsSGq3Uincfeg/EfzUR6IOQ0tl+Ui8sHqXG5jFcXBHgA455O6XRKyA6lUa3L/L3hvJSDmkDqj7dggeuxMXH+Jn6MPvgJYjgEX5s5+kBSxaviiBtF1iu2HUu/rsS9rHiZfn37KJeH8+LEgLZFpJswkyiQ==
  • Authentication-results: esa1.hc3370-68.iphmx.com; dkim=pass (signature verified) header.i=@citrix.onmicrosoft.com
  • Cc: Jan Beulich <JBeulich@xxxxxxxx>, Roger Pau Monné <roger.pau@xxxxxxxxxx>, Wei Liu <wl@xxxxxxx>
  • Delivery-date: Mon, 03 May 2021 18:18:11 +0000
  • Ironport-hdrordr: A9a23:+/qxW6tpShlGXeB6vovBEKIW7skC2YYji2hD6mlwRA09T+WxrO rrtOgH1BPylTYaUGwhn9fFA6WbXXbA7/dOj7U5FYyJGC3ronGhIo0n14vtxDX8Bzbzn9Qz6Y 5JSII7MtH5CDFB4frSyBWkEtom3dmM+L2pg+Cb9Ht2UQR2cchbjztRICzzKDwTeCBtA50lGJ 2Aou9OoDS9cXoaB/7LeEUtde7FutHNidbaehYAHREq802jijmv5b78HXGjr2gjehlIxqov9n WArhzh6syYwo2G4zL/90uW1ZRZn9P91sBObfbstuE5Iijh4zzYH7hJdKaFuFkO0YeSwXYs1O LBuhIxe/l0gkmhA12dhTvI903e3C0163nkoGXo80fLhcDiXjo1B45gqOtiA2PkwnEttt19z6 5Htljx3/E8YGKi7UaNk+TgbB1kmlG5pnAvi4co/htieLATdaNLqsgn9F5Vea1wbx7S0pwtE+ VlEajnlY9rWG6dBkqp21VH/MahRTAaEBuAXyE5y7ao+gkTtnV4w0wE/dcYj3cN+bksIqM0l9 jsA+BGkqpDQdQRar84LOAdQdGvAmiIeh7UNnmOSG6XWp0vCjbokdra8b817OaldNghy4Yzoo 3IVBd9uXQpc0zjJMWS1PRwg1HwaVT4eQ6o5tBV5pB/tLG5bqHsKze/RFcnlNbli+kDA+XAMs zDeq5+MrvGFy/DCIxJ1wrxV915Mn8FSvAYvd49Rhanvt/LEIv3rebWGcyjZ4bFIHIBYCfSE3 EDVD/8KIFr9UawQEL1hxDXRjfDYUr60ZVsELXL3uQaxYQXX7c89jQ9uBCc3IWmODdCuqs5cA 9VO7X8iJ62omGw4CLp4gxSS11gJ3cQxI+lf2JBpAcMPU+xW60Eoc+jdWdb22bCAhd+SsjRAT NOvlgfw9PwE7WggQQZT/63OGOTiHUe4FiQSY0Hp6GF7cD5PrQ1E4ghQ640MQnQDRR6lUJLpQ 54GU85b36aMgmrpbSujZQSCu2aXcJ7mh2XLcldrm+ak16dq8EpTn4yRCWvTsaTvAYrS1Nv9x hM2p5apIDFtSekKGM5juh9GkZLcn6rDLVPCxnAWJ9ZgYnxeAZ7TX6DgBuTjx1bQBuyy2wiwk jaaQGEc/DCBVRQ/lRVyLzj/l9PemKBRE5ocXxhvYphFWPJh2Zr3YawF9+O+lrUTmFH7vAWMT nDbzdXGA9oytyt/DO+mTqJFxwdt9gTF92YKI5mX6DY23urJoHNqLoPGOVM+o15cPr0tPUQbO 6ZcwiJDT/xBu8zwTaJrnI9NCQckgh9rdrYnDneqESo1n82BvTfZGl8T7YAOteG8izKQe2L3J gRt6N8gcKAdkHKLviIxqHcY2Qddlf9oWuqQ/oprp4Rl6Qor7d3F4TaVzyN9Hwv5mRJEO7E0G clBIJ86/T9H6UqWeo4USdQ5EAom9SCN1FDiH29PsYOOXUWy0bGNNaI6YfSobUhAke9tBL9UG PvhBF1zrPgZW+/zrYUBKI7HHROZGU94Hpk+vmed4e4MnTiS8hzuH67OGS6arlTVeysHqgRtA 9z57iz7qOqXhu9/ADbpj1gJK1St06hXMOpGQqJXcpF6cazN1jJoqyk5qeI/XjKYAr+T0QTno tec0MMKuxFlzk5lYUylhGIdZafmDNvr3JupRd9llDs3YC64GDUWWF+WDep86l+bH10KXiHjc PM7O6C8m/yiQI1gqX+KA==
  • Ironport-sdr: f0vie2CDhUh7uhAFGRzbzO0+yGqIzSyk7Lz48kd0i+8UFFnZbBpEKFidN2bG2ap7gXVz9ZTaiC FlqQr7PDVRX7olxN2x12Ok0Nl0Dec5aP3UnvhWl1Zjx4kNfDA8D1N1HytvQwh6RiehAz6ew+H7 fWvLauZ6EqUYdkpyOJC058EFq2gFt/aidAf35vSQQRiKloImt7CCcz3gkNPv0lmLmZPt3fUCkT IQpWYI7IcbSBN5RsrLhQ47Hv2y7fh7o8P+BiGLOPtCyQDWjFgF/EwHFp6PGExVzizvMUMlpKCF Wzk=
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>

On 03/05/2021 16:39, Andrew Cooper wrote:
> We're soon going to need a compressed helper of the same form.
>
> The size of the uncompressed image is a strictly a property of the highest
> user state.  This can be calculated trivially with xstate_offsets/sizes, and
> is much faster than a CPUID instruction in the first place, let alone the two
> XCR0 writes surrounding it.
>
> Retain the cross-check with hardware in debug builds, but forgo it normal
> builds.  In particular, this means that the migration paths don't need to mess
> with XCR0 just to sanity check the buffer size.
>
> Signed-off-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>

The Qemu smoketests have actually found a bug here.

https://gitlab.com/xen-project/patchew/xen/-/jobs/1232118510/artifacts/file/smoke.serial

We call into xstate_uncompressed_size() from
hvm_register_CPU_save_and_restore() so the previous "xcr0 == 0" path was
critical to Xen not exploding on non-xsave platforms.

This is straight up buggy - we shouldn't be registering xsave handlers
on non-xsave platforms, but the calculation is also wrong (in the safe
directly at least) when we use compressed formats.  Yet another
unexpected surprise for the todo list.

~Andrew




 


Rackspace

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