From patchwork Thu Aug 11 06:11:42 2016 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Luwei Kang X-Patchwork-Id: 9274511 Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork.web.codeaurora.org (Postfix) with ESMTP id 0FE28600CB for ; Thu, 11 Aug 2016 06:14:46 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id F0585284EE for ; Thu, 11 Aug 2016 06:14:45 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id E4A5B284F1; Thu, 11 Aug 2016 06:14:45 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pdx-wl-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-4.2 required=2.0 tests=BAYES_00, RCVD_IN_DNSWL_MED autolearn=ham version=3.3.1 Received: from lists.xenproject.org (lists.xenproject.org [192.237.175.120]) (using TLSv1.2 with cipher AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.wl.linuxfoundation.org (Postfix) with ESMTPS id 18BA3284EE for ; Thu, 11 Aug 2016 06:14:44 +0000 (UTC) Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bXjDb-0006Ya-OT; Thu, 11 Aug 2016 06:11:51 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xenproject.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bXjDa-0006YT-C8 for xen-devel@lists.xen.org; Thu, 11 Aug 2016 06:11:50 +0000 Received: from [85.158.139.211] by server-6.bemta-5.messagelabs.com id AE/40-29022-5271CA75; Thu, 11 Aug 2016 06:11:49 +0000 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrGKsWRWlGSWpSXmKPExsXS1tYhoqsivib cYG67vsWSj4tZHBg9ju7+zRTAGMWamZeUX5HAmnGu7yRbwSbDiqNznBsYT6l3MXJyCAlUSHTP PMkCYksI8EocWTaDFcIOkJj2cC9jFyMXUE0Do8Su5Q+ZIJw9jBKHj9xlhXB2MUpc236fDcJZw yixbUYTE0g/m4CWxJPdz9lAbBEBP4m2170sIEXMAvMYJXYf7QIrEhawkXjaPIkdoshWYtaa6e wgRSICXUBF6zrBulkEVCVWzjjFCGLzCgRLXH0ymQni8rNsEvv+V4LYnAL2EvNnPwGLMwqISXw /tQbMZhYQl7j1ZD4TxEcCEkv2nGeGsEUlXj7+B/WpvMT8y9/ArpMQWMgssWpOExtEQlHi7/pW RohBOhILdn9ig7C1JZYtfM0McZCgxMmZT1ggDlKUeDhzDvsERplZSHbPQtI+C0n7LCTtCxhZV jGqF6cWlaUW6VroJRVlpmeU5CZm5ugaGpjq5aYWFyemp+YkJhXrJefnbmIExjcDEOxgPNjsfI hRkoNJSZRXOGZ1uBBfUn5KZUZicUZ8UWlOavEhRhkODiUJXkaxNeFCgkWp6akVaZk5wEQDk5b g4FES4ZUASfMWFyTmFmemQ6ROMSpKifPeEAVKCIAkMkrz4Npgye0So6yUMC8j0CFCPAWpRbmZ JajyrxjFORiVhHmVQcbzZOaVwE1/BbSYCWhxkuoKkMUliQgpqQZG84tsC5budP3z6d/dNXaNn zUdlRS70xrrE4/6siVr5OWzW3+b4mLzdIrlyvO50z6pzpt997zszR+el6M4jNZ6se6z/C+rcl jG2Xn+qTU3tiy/IhqymXP3syfr1m6uz5K4OyN30YJ0u69y/znOV3/PNtoxMy/3qWP87jPNnFL 6BuXsnM+vh05ZosRSnJFoqMVcVJwIAEaIBlFpAwAA X-Env-Sender: luwei.kang@intel.com X-Msg-Ref: server-11.tower-206.messagelabs.com!1470895907!41779520!1 X-Originating-IP: [134.134.136.20] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTM0LjEzNC4xMzYuMjAgPT4gMzU1MzU4\n X-StarScan-Received: X-StarScan-Version: 8.84; banners=-,-,- X-VirusChecked: Checked Received: (qmail 64106 invoked from network); 11 Aug 2016 06:11:48 -0000 Received: from mga02.intel.com (HELO mga02.intel.com) (134.134.136.20) by server-11.tower-206.messagelabs.com with SMTP; 11 Aug 2016 06:11:48 -0000 Received: from orsmga001.jf.intel.com ([10.7.209.18]) by orsmga101.jf.intel.com with ESMTP; 10 Aug 2016 23:11:47 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos; i="5.28,503,1464678000"; d="scan'208"; a="1012365558" Received: from fmsmsx104.amr.corp.intel.com ([10.18.124.202]) by orsmga001.jf.intel.com with ESMTP; 10 Aug 2016 23:11:46 -0700 Received: from fmsmsx121.amr.corp.intel.com (10.18.125.36) by fmsmsx104.amr.corp.intel.com (10.18.124.202) with Microsoft SMTP Server (TLS) id 14.3.248.2; Wed, 10 Aug 2016 23:11:46 -0700 Received: from shsmsx103.ccr.corp.intel.com (10.239.4.69) by fmsmsx121.amr.corp.intel.com (10.18.125.36) with Microsoft SMTP Server (TLS) id 14.3.248.2; Wed, 10 Aug 2016 23:11:46 -0700 Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.8]) by SHSMSX103.ccr.corp.intel.com ([169.254.4.181]) with mapi id 14.03.0248.002; Thu, 11 Aug 2016 14:11:44 +0800 From: "Kang, Luwei" To: Jan Beulich , Andrew Cooper Thread-Topic: [PATCH v4] x86/cpuid: AVX-512 Feature Detection Thread-Index: AQHR0pNLTJDNJb1j8keMYWd2F29Ju6ACsNyAgAZx5BD//8ikAIADYSJwgBHR0gCACrEswP//srAAgA4kshD///XSAAFucg6w//+ovQCAABwCAIAACH+A//5bivA= Date: Thu, 11 Aug 2016 06:11:42 +0000 Message-ID: <82D7661F83C1A047AF7DC287873BF1E136AEEE1E@SHSMSX101.ccr.corp.intel.com> References: <1467265812-5872-1-git-send-email-luwei.kang@intel.com> <57763E4702000078000FA4D6@prv-mh.provo.novell.com> <82D7661F83C1A047AF7DC287873BF1E136AE05E5@SHSMSX101.ccr.corp.intel.com> <577B77DE02000078000FB265@prv-mh.provo.novell.com> <82D7661F83C1A047AF7DC287873BF1E136AE10DD@SHSMSX101.ccr.corp.intel.com> <0000b4dc-35b3-2ff3-51f2-3e71cae7afcd@citrix.com> <82D7661F83C1A047AF7DC287873BF1E136AE87F9@SHSMSX101.ccr.corp.intel.com> <82D7661F83C1A047AF7DC287873BF1E136AECC2D@SHSMSX101.ccr.corp.intel.com> <57A1CC4C0200007800102129@prv-mh.provo.novell.com> <82D7661F83C1A047AF7DC287873BF1E136AEEAE4@SHSMSX101.ccr.corp.intel.com> <57AB1E4602000078001049FE@prv-mh.provo.novell.com> <57AB3CE50200007800104AE7@prv-mh.provo.novell.com> In-Reply-To: <57AB3CE50200007800104AE7@prv-mh.provo.novell.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ctpclassification: CTP_PUBLIC x-titus-metadata-40: eyJDYXRlZ29yeUxhYmVscyI6IiIsIk1ldGFkYXRhIjp7Im5zIjoiaHR0cDpcL1wvd3d3LnRpdHVzLmNvbVwvbnNcL0ludGVsMyIsImlkIjoiMmNkZDk5MmItMDZiZi00NWExLWEwMTYtNmQ3NmE1MWM3NTgzIiwicHJvcHMiOlt7Im4iOiJDVFBDbGFzc2lmaWNhdGlvbiIsInZhbHMiOlt7InZhbHVlIjoiQ1RQX1BVQkxJQyJ9XX1dfSwiU3ViamVjdExhYmVscyI6W10sIlRNQ1ZlcnNpb24iOiIxNS45LjYuNiIsIlRydXN0ZWRMYWJlbEhhc2giOiI2c1RZVXp2WGF4UWM3cTkrakFsZm9sd1QrY1dDN0IzT1RFZWxUcGxsTzJVPSJ9 x-originating-ip: [10.239.127.40] MIME-Version: 1.0 Cc: "chao.p.peng@linux.intel.com" , "Wang, Yong Y" , "xen-devel@lists.xen.org" Subject: Re: [Xen-devel] [PATCH v4] x86/cpuid: AVX-512 Feature Detection X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xen.org Sender: "Xen-devel" X-Virus-Scanned: ClamAV using ClamSMTP > >>> On 10.08.16 at 14:10, wrote: > > On 10/08/16 11:29, Jan Beulich wrote: > >>>>> On 10.08.16 at 11:58, wrote: > >>>>>>> On 03.08.16 at 03:32, wrote: > >>>>>> On 25/07/16 07:09, Kang, Luwei wrote: > >>>>>>>>>> First of all - please don't top post. > >>>>>>>>>> > >>>>>>>>>>> What about remove the dependency between AVX2 and AVX512F > >>>>>>>> ( AVX2: > >>>>>>>>>> [AVX512F], ) ? > >>>>>>>>>> > >>>>>>>>>> Yes, that's what I think we want, but we need Andrew's agreement here. > >>>>>>>>>> > >>>>>>>>> Hi Andrew, what is your opinion ? > >>>>>>>> You are in a better position to answer than me. > >>>>>>>> > >>>>>>>> For a specific instruction which may be VEX and EVEX encoded, > >>>>>>>> is the circuitry for a specific instruction shared, or > >>>>>>>> discrete? Is there a plausible future where you might support > >>>>>>>> only the EVEX variant of an instruction, and not the VEX variant? > >>>>>>>> > >>>>>>>> These dependences are about what may be reasonably assumed > >>>>>>>> about the way the environment is structured. It doesn't look > >>>>>>>> reasonable to advertise an AVX512 environment to guests while > >>>>>>>> at the same time stating that AVX2 is not present. If this is > >>>>>>>> correct, then the dependency > >>>>> should stay. > >>>>>>>> If Intel plausibly things it might release hardware with !AVX2 > >>>>>>>> but AVX512, then the dependency should be dropped. > >>>>>>> Regarding the dependency between AVX2 and AVX512F, I have ask > >>>>>>> some hardware > >>>>> architecture engineer. > >>>>>>> AVX512 is a superset of AVX2, the most important item being the > >>>>>>> state. If > >>>>> the state for AVX2 isn't enabled (in XCR0), then AVX512 > >>>>>> also can't function. > >>>>>>> So if we want to use AVX512, AVX2 must be supported and enabled. > >>>>>>> The > >>>>> dependence between AVX512F and AVX2 may need be > >>>>>> reserved. > >>>>>> > >>>>>> Ok, so AVX512 strictly depends on AVX2. > >>>>>> > >>>>>> In which case, the python code was correct. The meaning of the > >>>>>> key/value > >>>>> relationship is "if the feature in the key is not present, all > >>>>>> features in the value must also be disabled". > >>>>> Hi jan, what is your opinion? > >>>> There's no opinion to be had here, according to your earlier reply. > >>>> I do, > >>> however, continue to question that model: State and > >>>> instruction set are independent items. Of course YMM state is a > >>>> prereq to > >>> ZMM state, but I do not buy AVX2 insn support being a > >>>> prereq to AVX-512 insns. Yet to me the AVX2 and AVX-512F feature > >>>> flags solely > >>> represent the instructions, while the XSTATE leaf bits > >>>> represent the states. > >>>> > >>> Hi jan, > >>> I get some information from hardware colleague. There is no > >>> dependence about AVX512 instructions and AVX2 instructions. It is > >>> also not states in > > the > >>> official document. > >> As I had assumed. > >> > >>> But I want to know the meaning of the dependence "AVX2: > >>> [AVX512F]" in "gen-cpuid.py" file. > >>> If it is the feature dependence, I think the dependence between > >>> AVX512 and AVX2 may need to add. As we talk before, Zmm is part of AVX512 feature. > > > >>> If the state for AVX2 isn't enabled (in XCR0), then AVX512 also > >>> can't function. Apart from that, there is no processors with AVX512 > >>> without AVX2 currently and it is safe to treat AVX2 as part of the > >>> thermometer leading to > > > >>> AVX512. Regarding if will have a cpu support avx512 without avx2 in > >>> future, it is really hard to say. > >>> If it is the instructions dependence, I have no idea to delete > >>> this dependence in "gen-cpuid.py" file. > >>> So, I want to know your advice. > >> Well, the main issue here is that we have no feature flag > >> representation for the xstate bits. If we had, the relevant parts of > >> the dependencies should look like > >> > >> XSTATE_YMM: [AVX, XSTATE_ZMM] > >> AVX: [AVX2] > >> XSTATE_ZMM: [AVX512F] > >> AVX512F: [AVX512CD, ...] > >> > >> But in their absence I guess keeping the AVX2 dependency as you have > >> it is the only reasonable approach. Just that I'd like it to be > >> accompanied by a comment explaining that this isn't the actual > >> dependency (so that if XSTATE feature flags got introduced later, it > >> would be clear how to adjust those parts). > >> > >> Andrew - I keep forgetting why you think having such XSTATE_* feature > >> flags is not appropriate. > > > > This is all about providing a plausible cpuid layout to a guest. > > > > It is not plausible that we will ever see a processor with e.g. > > AVX512F but not XSTATE_ZMM. > > This is a somewhat bogus argument considering we have > > FXSR: [FFXSR, SSE], > > which, as you certainly realize, is slightly wrong nowadays: > XSTATE_XMM would suffice as a prereq, without any FXSR. (But I certainly realize that lack of FXSR is unlikely, as that's considered part > of the base x86-64 architecture, and I also realize that expressing alternative prereqs would make the deep dependency generation > logic more complicated.) > According your advice, I change the comment of "AVX2: [AVX512F]," as below. If the description is not accurately enough, please help do some corrected, thank you. diff --git a/xen/tools/gen-cpuid.py b/xen/tools/gen-cpuid.py index 7c45eca..e8b64ce 100755 --- a/xen/tools/gen-cpuid.py +++ b/xen/tools/gen-cpuid.py @@ -243,6 +243,17 @@ def crunch_numbers(state): # AMD K6-2+ and K6-III processors shipped with 3DNow+, beyond the # standard 3DNow in the earlier K6 processors. _3DNOW: [_3DNOWEXT], + + # This is just the dependency between AVX512 and AVX2 of XSTATE feature flag. + # If want to use AVX512, AVX2 must be supported and enabled. + AVX2: [AVX512F], + + # AVX512F is taken to mean hardware support for EVEX encoded instructions, + # 512bit registers, and the instructions themselves. All further AVX512 features + # are built on top of AVX512F + AVX512F: [AVX512DQ, AVX512IFMA, AVX512PF, AVX512ER, AVX512CD, + AVX512BW, AVX512VL, AVX512VBMI], } deep_features = tuple(sorted(deps.keys()))