Received: by 2002:a25:c593:0:0:0:0:0 with SMTP id v141csp5675686ybe; Tue, 17 Sep 2019 11:41:03 -0700 (PDT) X-Google-Smtp-Source: APXvYqwPYEe9DweE/iDFrCcVdLsJnazhgG/rkHAyalMoPAbSQrFI0tMY6xoPUbAql1HhPpM4Y9FQ X-Received: by 2002:a05:6402:2cb:: with SMTP id b11mr6246180edx.285.1568745663815; Tue, 17 Sep 2019 11:41:03 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1568745663; cv=none; d=google.com; s=arc-20160816; b=WiP4J+jLnt+spDtul2K0idyLn0YB8N+5XeQA6XQ3lrZEE/P3BAyUW48Fg5Geb50M0v RyT1C0TETIHgJKemHvR45t31Kb6AuQD/zgXKxgblBTywJLoEJ/TUXBOC2V5yKy3uhj1D viP4d8GNUBpOjLdW7vDljMLonCAX6cgmJHfBd+PjI5P3AE9KyyapLZAt5KS46D0bew69 VenWuHh8/CPeVQGZG0zuZl4C1Xx9Htci/8Kqu4VwDd0yJkYxpqyzR+KqsPDevMY1MXso HpFOucgfBU6EMF/C4xLG+hzoxP5DyGNqcFcHn+2WnSo4SFYHeCYz89PzHh3FsOOQKhOn q1FQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:mime-version:content-transfer-encoding :user-agent:message-id:date:references:in-reply-to:cc:to:subject :from; bh=mI6FVZrsiJZjCGsJND9HMErBUOOhCVeAr9XtvYcKxLw=; b=qMN1Fzrjlih/b+GNrHUQ770ArvdjZhn1DqRJCU9furxHGNw/Qg18bh4UNUUIaAwedR 8B4OXNxmb+jx5w9+QP9ruucSlp36EkO1Ewjuh8Ykm50uIP5z9zXT/j4a39pSZ9+dZAOL w6GGaJ41Z4aoCC8f3+ZzwM5OZt2fsyrdWO4+5l6ZbJO2cN4ufOqf8RGUrxYil8yO0tYZ 3jigSG3o+PyaPK2nQAHMuXvSGpICUNV/hloPxz8KZoTDqEgh0OvidP5cb4XqCdZFCZ+A 108x7MoqmgK7euMaVQaNeOXI3BoMdLHYo82M+mN/Rk+d49NL9edXiqfDAihHC2aBUQUy Hm8A== 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=bitdefender.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id g13si1547846ejf.133.2019.09.17.11.40.40; Tue, 17 Sep 2019 11:41:03 -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=bitdefender.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1730373AbfIQQdx (ORCPT + 99 others); Tue, 17 Sep 2019 12:33:53 -0400 Received: from mx01.bbu.dsd.mx.bitdefender.com ([91.199.104.161]:46504 "EHLO mx01.bbu.dsd.mx.bitdefender.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1730330AbfIQQdx (ORCPT ); Tue, 17 Sep 2019 12:33:53 -0400 X-Greylist: delayed 603 seconds by postgrey-1.27 at vger.kernel.org; Tue, 17 Sep 2019 12:33:52 EDT Received: from smtp.bitdefender.com (smtp01.buh.bitdefender.com [10.17.80.75]) by mx01.bbu.dsd.mx.bitdefender.com (Postfix) with ESMTPS id B7930307489B; Tue, 17 Sep 2019 19:23:48 +0300 (EEST) Received: from localhost (unknown [195.210.4.22]) by smtp.bitdefender.com (Postfix) with ESMTPSA id 9F14130BC822; Tue, 17 Sep 2019 19:23:48 +0300 (EEST) From: Adalbert =?iso-8859-2?b?TGF643I=?= Subject: Re: [PATCH v5 0/9] Enable Sub-page Write Protection Support To: Konrad Rzeszutek Wilk , Yang Weijiang Cc: kvm@vger.kernel.org, linux-kernel@vger.kernel.org, pbonzini@redhat.com, sean.j.christopherson@intel.com, mst@redhat.com, rkrcmar@redhat.com, jmattson@google.com, yu.c.zhang@intel.com In-Reply-To: <20190917125904.GB22162@char.us.oracle.com> References: <20190917085304.16987-1-weijiang.yang@intel.com> <20190917125904.GB22162@char.us.oracle.com> Date: Tue, 17 Sep 2019 19:24:15 +0300 Message-ID: <15687374550.b5d3c.30742@host> User-agent: void Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, 17 Sep 2019 08:59:04 -0400, Konrad Rzeszutek Wilk wrote: > On Tue, Sep 17, 2019 at 04:52:55PM +0800, Yang Weijiang wrote: > > EPT-Based Sub-Page write Protection(SPP)is a HW capability which allows > > Virtual Machine Monitor(VMM) to specify write-permission for guest > > physical memory at a sub-page(128 byte) granularity. When this > > capability is enabled, the CPU enforces write-access check for sub-pages > > within a 4KB page. > > > > The feature is targeted to provide fine-grained memory protection for > > usages such as device virtualization, memory check-point and VM > > introspection etc. > > > > SPP is active when the "sub-page write protection" (bit 23) is 1 in > > Secondary VM-Execution Controls. The feature is backed with a Sub-Page > > Permission Table(SPPT), SPPT is referenced via a 64-bit control field > > called Sub-Page Permission Table Pointer (SPPTP) which contains a > > 4K-aligned physical address. > > > > To enable SPP for certain physical page, the gfn should be first mapped > > to a 4KB entry, then set bit 61 of the corresponding EPT leaf entry. > > While HW walks EPT, if bit 61 is set, it traverses SPPT with the guset > > physical address to find out the sub-page permissions at the leaf entry. > > If the corresponding bit is set, write to sub-page is permitted, > > otherwise, SPP induced EPT violation is generated. > > > > This patch serial passed SPP function test and selftest on Ice-Lake platform. > > > > Please refer to the SPP introduction document in this patch set and > > Intel SDM for details: > > > > Intel SDM: > > https://software.intel.com/sites/default/files/managed/39/c5/325462-sdm-vol-1-2abcd-3abcd.pdf > > > > SPP selftest patch: > > https://lkml.org/lkml/2019/6/18/1197 > > > > Previous patch: > > https://lkml.org/lkml/2019/8/14/97 > > I saw the patches as part of the introspection patch-set. > Are you all working together on this? Weijiang helped us to start using the SPP feature with the introspection API and tested the integration when we didn't had the hardware available. I've included the SPP patches in the introspection patch series in order to "show the full picture". > Would it be possible for some of the bitdefender folks who depend on this > to provide Tested-by adn could they also take the time to review this patch-set? Sure. Once we rebase the introspection patches on 5.3, we'll replace the previous version this new one in our tree and test it.