From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-7.3 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, NICE_REPLY_A,SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 64E2CC433B4 for ; Mon, 17 May 2021 07:33:44 +0000 (UTC) Received: from lists.xenproject.org (lists.xenproject.org [192.237.175.120]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 28531611C2 for ; Mon, 17 May 2021 07:33:44 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 28531611C2 Authentication-Results: mail.kernel.org; dmarc=fail (p=quarantine dis=none) header.from=suse.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=xen-devel-bounces@lists.xenproject.org Received: from list by lists.xenproject.org with outflank-mailman.128093.240547 (Exim 4.92) (envelope-from ) id 1liXkn-00011r-51; Mon, 17 May 2021 07:33:29 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 128093.240547; Mon, 17 May 2021 07:33:29 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1liXkn-00011k-1i; Mon, 17 May 2021 07:33:29 +0000 Received: by outflank-mailman (input) for mailman id 128093; Mon, 17 May 2021 07:33:27 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1liXkl-00011e-LS for xen-devel@lists.xenproject.org; Mon, 17 May 2021 07:33:27 +0000 Received: from mx2.suse.de (unknown [195.135.220.15]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id cfab9a4d-a304-4965-8c03-bf02bdc275a1; Mon, 17 May 2021 07:33:26 +0000 (UTC) Received: from relay2.suse.de (unknown [195.135.221.27]) by mx2.suse.de (Postfix) with ESMTP id 9E385AEC5; Mon, 17 May 2021 07:33:25 +0000 (UTC) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: cfab9a4d-a304-4965-8c03-bf02bdc275a1 X-Virus-Scanned: by amavisd-new at test-mx.suse.de DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1; t=1621236805; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=24Z/UW0NpvL4JqusYZlmgtoTjXyjdYgR/Gpy6zpGA+o=; b=vSsm2BzQPq4+Xaq1c2uTlCwIZM8THIWuVZOTH3YTcnKBRwjwui7CP4Xx8t9+66YSi0VPYy p2ZamSZzoTshLGX2KHLgmOWQyGGiM5rJMxPFCfkVO3Qxp89QMwk2dHWvwIWufqWZyTdP3n saTJFtZ/qigFA2ZqrZRvVafsMEmGj5I= Subject: Re: [PATCH v3 03/22] x86/xstate: re-size save area when CPUID policy changes To: Andrew Cooper Cc: George Dunlap , Ian Jackson , Julien Grall , Stefano Stabellini , Wei Liu , =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= , "xen-devel@lists.xenproject.org" References: <322de6db-e01f-0b57-5777-5d94a13c441a@suse.com> <8ba8f016-0aed-277b-bbea-80022d057791@suse.com> <5a954be8-e213-36d8-27da-4c51243dc280@citrix.com> From: Jan Beulich Message-ID: Date: Mon, 17 May 2021 09:33:33 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.10.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit On 11.05.2021 18:41, Andrew Cooper wrote: > 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. Not sure about the need to eliminate the xcr0=0 (or xstates=0) case. Which isn't to say I'm opposed if you want to do so and it's not overly intrusive. > I think we also want a rule that Xen will always send compressed if it > is using XSAVES (/XSAVEC in the interim?) If this is sufficiently neutral to tool stack code, why not (albeit I don't think there needs to be a "rule" - Xen should be free to provide what it deems best, with consumers in the position to easily recognize the format; similarly Xen should be consuming whatever it gets handed, as long as that's valid state). Luckily the layout is visible just through tool-stack-only interfaces. >  We do not want to be working > with uncompressed images at all, now that MPX is a reasonable sized hole > in the middle. They're together no larger (128 bytes) than the LWP hole right ahead of them (at 0x340). I agree avoiding uncompressed format is worthwhile, but perhaps quite a bit more so for systems with higher components following unavailable even bigger ones. Jan