Received: by 2002:a25:8b12:0:0:0:0:0 with SMTP id i18csp2311345ybl; Thu, 15 Aug 2019 09:46:39 -0700 (PDT) X-Google-Smtp-Source: APXvYqztF1Xea2VVCsfkQWidHUCR4xSF99Z3PaKvkw6XbsYEVMALI8ja7upU8rjjFihyZzfdVCNm X-Received: by 2002:a17:902:a612:: with SMTP id u18mr4980984plq.181.1565887599370; Thu, 15 Aug 2019 09:46:39 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1565887599; cv=none; d=google.com; s=arc-20160816; b=eP1BUmzo4L9RHExKD6ZcgYemUuDI9hKlGvSG3qYZgCZIYHptAcFmTrWLA66kCJewHc bw1VIVobmGjfRtl6jdpEJ7E0lMU2k+W102JII5p9NSRRTdneh91xmjC4GnuSp/pb9Eh/ FDVD6+KepHZwcbIsA2DKm/Ir4zrltry5ZKHgUdXqCBDFFcQDCAcBLmXN88hi/kh1ckTe e55rM8r7SLBtQoqiFK5Y1RHC9gA+vZ0AyHgBYDlYw0mMTCuJ5qLGQ0kf+RI5HWerZQ3D E++LcB7tCB24l24oJmJufLWGF+Ru6MEdDiYiL6btvKbkmi+4d3OMlesiF//dHbrw4kQM EXhw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date; bh=WBBuBqXZhrijJ2MDZKJc2d6glrQm+KV9QBP1gvE0CY4=; b=PT6l5qJDZ4pMc8NAlCBfbX0m1CCr0elD92fIJFuQFsEpfX9ofghZ1777QbYjZGahae QCrj14fZ1ZWZPZB3svyOW7k9R1vRfWjw+ww5lSCPtVL+s/bnylPfJstPM/jE65HWU5mH 5zKfc0AUI0fnzkQk81PyUWzRJ4Rlkv0Hcpx1EcxccrYpAUH9bRxX41uLBCIbAuLfK+23 04/Aa7E30nC2MmvclKuI+wNK4uEXlbV4m3a6RCEwAXm+HdkulaQry2+8m1852vsG3e0E Av5pfUrFe2ygyi+ucLjnq91djeMhOiz1LD7ggRplCvbpz4bqSM/kQETksT4Z7Qi+G2dv u6WA== 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=intel.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id v12si2114228pgl.102.2019.08.15.09.46.24; Thu, 15 Aug 2019 09:46:39 -0700 (PDT) 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=intel.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1732122AbfHOQir (ORCPT + 99 others); Thu, 15 Aug 2019 12:38:47 -0400 Received: from mga09.intel.com ([134.134.136.24]:22205 "EHLO mga09.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1731913AbfHOQiq (ORCPT ); Thu, 15 Aug 2019 12:38:46 -0400 X-Amp-Result: UNSCANNABLE X-Amp-File-Uploaded: False Received: from fmsmga007.fm.intel.com ([10.253.24.52]) by orsmga102.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 15 Aug 2019 09:38:45 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.64,389,1559545200"; d="scan'208";a="178512101" Received: from sjchrist-coffee.jf.intel.com (HELO linux.intel.com) ([10.54.74.41]) by fmsmga007.fm.intel.com with ESMTP; 15 Aug 2019 09:38:44 -0700 Date: Thu, 15 Aug 2019 09:38:44 -0700 From: Sean Christopherson To: Jim Mattson Cc: Yang Weijiang , Vitaly Kuznetsov , kvm list , LKML , "Michael S. Tsirkin" , Radim =?utf-8?B?S3LEjW3DocWZ?= , yu.c.zhang@intel.com, alazar@bitdefender.com, Paolo Bonzini Subject: Re: [PATCH RESEND v4 5/9] KVM: VMX: Add init/set/get functions for SPP Message-ID: <20190815163844.GD27076@linux.intel.com> References: <20190814070403.6588-1-weijiang.yang@intel.com> <20190814070403.6588-6-weijiang.yang@intel.com> <87a7cbapdw.fsf@vitty.brq.redhat.com> <20190815134329.GA11449@local-michael-cet-test> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Aug 15, 2019 at 09:25:41AM -0700, Jim Mattson wrote: > On Thu, Aug 15, 2019 at 6:41 AM Yang Weijiang wrote: > > > Hi, Vitaly, > > After looked into the issue and others, I feel to make SPP co-existing > > with nested VM is not good, the major reason is, L1 pages protected by > > SPP are transparent to L1 VM, if it launches L2 VM, probably the > > pages would be allocated to L2 VM, and that will bother to L1 and L2. > > Given the feature is new and I don't see nested VM can benefit > > from it right now, I would like to make SPP and nested feature mutually > > exclusive, i.e., detecting if the other part is active before activate one > > feature,what do you think of it? > > thanks! > > How do you propose making the features mutually exclusive? I haven't looked at the details or the end to end flow, but would it make sense to exit to userspace on nested VMLAUNCH/VMRESUME if there are SPP mappings? And have the SPP ioctl() kick vCPUs out of guest. KVM already exits on SPP violations, so presumably this is something that can be punted to userspace.