Received: by 2002:ac0:aed5:0:0:0:0:0 with SMTP id t21csp6070447imb; Fri, 8 Mar 2019 08:38:33 -0800 (PST) X-Google-Smtp-Source: APXvYqyKjlt/2XRNO5TtR2fwQfPlZSHiMjOPrOYndME6J13mIS0mD0rBH44iNekIjwZ8k3xvcb5t X-Received: by 2002:aa7:8c4d:: with SMTP id e13mr19516124pfd.53.1552063113770; Fri, 08 Mar 2019 08:38:33 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1552063113; cv=none; d=google.com; s=arc-20160816; b=YKoqCcNAQinN/SAVtcnktHY563UFWdVqeZgFr5mpCXKf2r5DC0q8sEtbGRu2t6oZ9k wGttg/KJt3SGL7GL1OzHpyeg9YkPKnsLkZ+41KlqMgNL2SaMM48pcZewvmbbumB8cNpo C1BIZBI2nBMZj/zeSl91T8qAwRB3EUz5m7eLMfdI15UKhVXWehog0vqbOgxJv4gRqe+F TnLQLXl/fJgJ6niXZeiKobxm83DYQt0EQI+Ai0dQF3rTXNX87Iryt5fSzX7XvNENtzHH FswFg2VMfyzQ8eKp26FOfCBVTxu43KGYcJqdL2wr3bTedXHziZcKDpNmojup5CgYi0iQ 5B3A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding :content-language:in-reply-to:mime-version:user-agent:date :message-id:autocrypt:openpgp:from:references:cc:to:subject; bh=YGB1HuTVJ2RC6Ph0JVHBX1yi5fvMMln4h7GKryrlm6s=; b=S8OCXmqsKJzw2WOsTlYSgWRscvEKC2bHgnKtz9jKXwvSeBcq4EfFW24V3mDH4OGFsf /DjxSVzTF7oOyfotjkUADRcFjZ+fIAg5Za+7kXVFr6X+TG4e2EyEN4mOrq4XC/R4ghDS qSBheXPpQJs04bmattd04X5LIosGCeL9fYU64ZaCdSOMxRuEMrpl3wQ5UMJM28pxWBsD LK16vdTV8G6DUcIxXRDS2KOJ/Oh2F+ocKYYmLOdI2DljAjmJBYK8HR0NjUUTau6h9d/j 0aagxrHLHJ9X8KzPzQ5SCEiIc+2u/8qKuGDwFnVYIAtEHk8YCDPsOgMwnNBahjXkv/rI Oo9A== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=redhat.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id o26si7497039pfi.141.2019.03.08.08.38.18; Fri, 08 Mar 2019 08:38:33 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726550AbfCHQhH (ORCPT + 99 others); Fri, 8 Mar 2019 11:37:07 -0500 Received: from mx1.redhat.com ([209.132.183.28]:57326 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726249AbfCHQhH (ORCPT ); Fri, 8 Mar 2019 11:37:07 -0500 Received: from smtp.corp.redhat.com (int-mx05.intmail.prod.int.phx2.redhat.com [10.5.11.15]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 9C2FE87649; Fri, 8 Mar 2019 16:37:06 +0000 (UTC) Received: from [10.36.112.16] (ovpn-112-16.ams2.redhat.com [10.36.112.16]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 6C9365D786; Fri, 8 Mar 2019 16:36:54 +0000 (UTC) Subject: Re: [PATCH v3 6/8] KVM:VMX: Load Guest CET via VMCS when CET is enabled in Guest To: Sean Christopherson , Yang Weijiang Cc: rkrcmar@redhat.com, jmattson@google.com, linux-kernel@vger.kernel.org, kvm@vger.kernel.org, mst@redhat.com, yu-cheng.yu@intel.com, Zhang Yi Z , wei.w.wang@intel.com, weijiang.yang@inte.com References: <20190225132716.6982-1-weijiang.yang@intel.com> <20190225132716.6982-7-weijiang.yang@intel.com> <20190228161715.GF6166@linux.intel.com> <20190228083844.GC12006@local-michael-cet-test.sh.intel.com> <20190301145819.GC22584@linux.intel.com> <20190303122608.GA32013@local-michael-cet-test.sh.intel.com> <20190304184307.GC17120@linux.intel.com> <20190304095640.GA3576@local-michael-cet-test.sh.intel.com> <20190305031202.GI17120@linux.intel.com> <20190304123655.GB4185@local-michael-cet-test.sh.intel.com> <20190308162835.GB2528@linux.intel.com> From: Paolo Bonzini Openpgp: preference=signencrypt Autocrypt: addr=pbonzini@redhat.com; prefer-encrypt=mutual; keydata= mQHhBFRCcBIBDqDGsz4K0zZun3jh+U6Z9wNGLKQ0kSFyjN38gMqU1SfP+TUNQepFHb/Gc0E2 CxXPkIBTvYY+ZPkoTh5xF9oS1jqI8iRLzouzF8yXs3QjQIZ2SfuCxSVwlV65jotcjD2FTN04 hVopm9llFijNZpVIOGUTqzM4U55sdsCcZUluWM6x4HSOdw5F5Utxfp1wOjD/v92Lrax0hjiX DResHSt48q+8FrZzY+AUbkUS+Jm34qjswdrgsC5uxeVcLkBgWLmov2kMaMROT0YmFY6A3m1S P/kXmHDXxhe23gKb3dgwxUTpENDBGcfEzrzilWueOeUWiOcWuFOed/C3SyijBx3Av/lbCsHU Vx6pMycNTdzU1BuAroB+Y3mNEuW56Yd44jlInzG2UOwt9XjjdKkJZ1g0P9dwptwLEgTEd3Fo UdhAQyRXGYO8oROiuh+RZ1lXp6AQ4ZjoyH8WLfTLf5g1EKCTc4C1sy1vQSdzIRu3rBIjAvnC tGZADei1IExLqB3uzXKzZ1BZ+Z8hnt2og9hb7H0y8diYfEk2w3R7wEr+Ehk5NQsT2MPI2QBd wEv1/Aj1DgUHZAHzG1QN9S8wNWQ6K9DqHZTBnI1hUlkp22zCSHK/6FwUCuYp1zcAEQEAAbQj UGFvbG8gQm9uemluaSA8cGJvbnppbmlAcmVkaGF0LmNvbT6JAg0EEwECACMFAlRCcBICGwMH CwkIBwMCAQYVCAIJCgsEFgIDAQIeAQIXgAAKCRB+FRAMzTZpsbceDp9IIN6BIA0Ol7MoB15E 11kRz/ewzryFY54tQlMnd4xxfH8MTQ/mm9I482YoSwPMdcWFAKnUX6Yo30tbLiNB8hzaHeRj jx12K+ptqYbg+cevgOtbLAlL9kNgLLcsGqC2829jBCUTVeMSZDrzS97ole/YEez2qFpPnTV0 VrRWClWVfYh+JfzpXmgyhbkuwUxNFk421s4Ajp3d8nPPFUGgBG5HOxzkAm7xb1cjAuJ+oi/K CHfkuN+fLZl/u3E/fw7vvOESApLU5o0icVXeakfSz0LsygEnekDbxPnE5af/9FEkXJD5EoYG SEahaEtgNrR4qsyxyAGYgZlS70vkSSYJ+iT2rrwEiDlo31MzRo6Ba2FfHBSJ7lcYdPT7bbk9 AO3hlNMhNdUhoQv7M5HsnqZ6unvSHOKmReNaS9egAGdRN0/GPDWr9wroyJ65ZNQsHl9nXBqE AukZNr5oJO5vxrYiAuuTSd6UI/xFkjtkzltG3mw5ao2bBpk/V/YuePrJsnPFHG7NhizrxttB nTuOSCMo45pfHQ+XYd5K1+Cv/NzZFNWscm5htJ0HznY+oOsZvHTyGz3v91pn51dkRYN0otqr bQ4tlFFuVjArBZcapSIe6NV8C4cEiSS5AQ0EVEJxcwEIAK+nUrsUz3aP2aBjIrX3a1+C+39R nctpNIPcJjFJ/8WafRiwcEuLjbvJ/4kyM6K7pWUIQftl1P8Woxwb5nqL7zEFHh5I+hKS3haO 5pgco//V0tWBGMKinjqntpd4U4Dl299dMBZ4rRbPvmI8rr63sCENxTnHhTECyHdGFpqSzWzy 97rH68uqMpxbUeggVwYkYihZNd8xt1+lf7GWYNEO/QV8ar/qbRPG6PEfiPPHQd/sldGYavmd //o6TQLSJsvJyJDt7KxulnNT8Q2X/OdEuVQsRT5glLaSAeVAABcLAEnNgmCIGkX7TnQF8a6w gHGrZIR9ZCoKvDxAr7RP6mPeS9sAEQEAAYkDEgQYAQIACQUCVEJxcwIbAgEpCRB+FRAMzTZp scBdIAQZAQIABgUCVEJxcwAKCRC/+9JfeMeug/SlCACl7QjRnwHo/VzENWD9G2VpUOd9eRnS DZGQmPo6Mp3Wy8vL7snGFBfRseT9BevXBSkxvtOnUUV2YbyLmolAODqUGzUI8ViF339poOYN i6Ffek0E19IMQ5+CilqJJ2d5ZvRfaq70LA/Ly9jmIwwX4auvXrWl99/2wCkqnWZI+PAepkcX JRD4KY2fsvRi64/aoQmcxTiyyR7q3/52Sqd4EdMfj0niYJV0Xb9nt8G57Dp9v3Ox5JeWZKXS krFqy1qyEIypIrqcMbtXM7LSmiQ8aJRM4ZHYbvgjChJKR4PsKNQZQlMWGUJO4nVFSkrixc9R Z49uIqQK3b3ENB1QkcdMg9cxsB0Onih8zR+Wp1uDZXnz1ekto+EivLQLqvTjCCwLxxJafwKI bqhQ+hGR9jF34EFur5eWt9jJGloEPVv0GgQflQaE+rRGe+3f5ZDgRe5Y/EJVNhBhKcafcbP8 MzmLRh3UDnYDwaeguYmxuSlMdjFL96YfhRBXs8tUw6SO9jtCgBvoOIBDCxxAJjShY4KIvEpK b2hSNr8KxzelKKlSXMtB1bbHbQxiQcerAipYiChUHq1raFc3V0eOyCXK205rLtknJHhM5pfG 6taABGAMvJgm/MrVILIxvBuERj1FRgcgoXtiBmLEJSb7akcrRlqe3MoPTntSTNvNzAJmfWhd SvP0G1WDLolqvX0OtKMppI91AWVu72f1kolJg43wbaKpRJg1GMkKEI3H+jrrlTBrNl/8e20m TElPRDKzPiowmXeZqFSS1A6Azv0TJoo9as+lWF+P4zCXt40+Zhh5hdHO38EV7vFAVG3iuay6 7ToF8Uy7tgc3mdH98WQSmHcn/H5PFYk3xTP3KHB7b0FZPdFPQXBZb9+tJeZBi9gMqcjMch+Y R8dmTcQRQX14bm5nXlBF7VpSOPZMR392LY7wzAvRdhz7aeIUkdO7VelaspFk2nT7wOj1Y6uL nRxQlLkBDQRUQnHuAQgAx4dxXO6/Zun0eVYOnr5GRl76+2UrAAemVv9Yfn2PbDIbxXqLff7o yVJIkw4WdhQIIvvtu5zH24iYjmdfbg8iWpP7NqxUQRUZJEWbx2CRwkMHtOmzQiQ2tSLjKh/c HeyFH68xjeLcinR7jXMrHQK+UCEw6jqi1oeZzGvfmxarUmS0uRuffAb589AJW50kkQK9VD/9 QC2FJISSUDnRC0PawGSZDXhmvITJMdD4TjYrePYhSY4uuIV02v028TVAaYbIhxvDY0hUQE4r 8ZbGRLn52bEzaIPgl1p/adKfeOUeMReg/CkyzQpmyB1TSk8lDMxQzCYHXAzwnGi8WU9iuE1P 0wARAQABiQHzBBgBAgAJBQJUQnHuAhsMAAoJEH4VEAzNNmmxp1EOoJy0uZggJm7gZKeJ7iUp eX4eqUtqelUw6gU2daz2hE/jsxsTbC/w5piHmk1H1VWDKEM4bQBTuiJ0bfo55SWsUNN+c9hh IX+Y8LEe22izK3w7mRpvGcg+/ZRG4DEMHLP6JVsv5GMpoYwYOmHnplOzCXHvmdlW0i6SrMsB Dl9rw4AtIa6bRwWLim1lQ6EM3PWifPrWSUPrPcw4OLSwFk0CPqC4HYv/7ZnASVkR5EERFF3+ 6iaaVi5OgBd81F1TCvCX2BEyIDRZLJNvX3TOd5FEN+lIrl26xecz876SvcOb5SL5SKg9/rCB ufdPSjojkGFWGziHiFaYhbuI2E+NfWLJtd+ZvWAAV+O0d8vFFSvriy9enJ8kxJwhC0ECbSKF Y+W1eTIhMD3aeAKY90drozWEyHhENf4l/V+Ja5vOnW+gCDQkGt2Y1lJAPPSIqZKvHzGShdh8 DduC0U3xYkfbGAUvbxeepjgzp0uEnBXfPTy09JGpgWbg0w91GyfT/ujKaGd4vxG2Ei+MMNDm S1SMx7wu0evvQ5kT9NPzyq8R2GIhVSiAd2jioGuTjX6AZCFv3ToO53DliFMkVTecLptsXaes uUHgL9dKIfvpm+rNXRn9wAwGjk0X/A== Message-ID: <9e80935f-b572-8210-6ea1-a582b3d05f88@redhat.com> Date: Fri, 8 Mar 2019 17:36:50 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.4.0 MIME-Version: 1.0 In-Reply-To: <20190308162835.GB2528@linux.intel.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.79 on 10.5.11.15 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.26]); Fri, 08 Mar 2019 16:37:06 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 08/03/19 17:28, Sean Christopherson wrote: > On Mon, Mar 04, 2019 at 08:36:55PM +0800, Yang Weijiang wrote: >> On Mon, Mar 04, 2019 at 07:12:02PM -0800, Sean Christopherson wrote: >>> On Mon, Mar 04, 2019 at 05:56:40PM +0800, Yang Weijiang wrote: >>>> Cannot agree with you more! >>>> This is some design limitation, but from my point of view, once vmm >>>> exposes CET capability to guest via CPUID, it grants the guest kernel freedom to choose >>>> which features to be enabled, we don't need to add extra constraints on >>>> the usage. >>> >>> But if KVM allows SHSTK and IBT to be toggled independently then the VMM >>> has only exposed SHSTK or IBT, not CET as whole. >>> >>> Even if SHSTK and IBT are bundled together the guest still has to opt-in >>> to enabling each feature. I don't see what we gain by pretending that >>> SHSTK/IBT can be individually exposed to the guest, and on the flip side >>> doing so creates a virtualization hole. >> you almost convinced me ;-), maybe I'll make the feature as a bundle in >> next release after check with kernel team. BTW, what do you mean by >> saying "create a virtualization hole"? Is it what you stated in above >> reply? > > By "virtualization hole" I mean the guest would be able to use a feature > that the virtual CPU model says isn't supported. I think it's okay to leave the hole and leave it to userspace to forbid enabling only one of the bits. Paolo > After rereading the XSS architecture, there's a marginally less crappy > option for handling XRSTOR as we could use the XSS_EXIT_BITMAP to > intercept XRSTOR if SHSTK != IBT and the guest is restoring CET state, > e.g. to ensure the guest isn't setting IA32_PL*_SSP if !SHSTK and isn't > setting bits that are effectively reserved in IA32_U_CET. > > But practically speaking that'd be the same as intercepting XRSTORS > unconditionally when the guest is using CET, i.e. it's still going to > tank the performance of a guest that uses CET+XSAVES/XRSTORS. >