Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Date:   Thu, 15 Dec 2022 14:10:38 -0800
From:   Isaku Yamahata <isaku.yamahata@gmail.com>
To:     "Huang, Kai" <kai.huang@intel.com>
Cc:     "kvm@vger.kernel.org" <kvm@vger.kernel.org>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
        "Yamahata, Isaku" <isaku.yamahata@intel.com>,
        "pbonzini@redhat.com" <pbonzini@redhat.com>,
        "Shahar, Sagi" <sagis@google.com>,
        "Aktas, Erdem" <erdemaktas@google.com>,
        "isaku.yamahata@gmail.com" <isaku.yamahata@gmail.com>,
        "dmatlack@google.com" <dmatlack@google.com>,
        "Christopherson,, Sean" <seanjc@google.com>
Subject: Re: [PATCH v10 046/108] KVM: Add flags to struct kvm_gfn_range
Message-ID: <20221215221038.GH3632095@ls.amr.corp.intel.com>
References: <cover.1667110240.git.isaku.yamahata@intel.com>
 <880c1016c29624964baee580985b6a736fc7d656.1667110240.git.isaku.yamahata@intel.com>
 <ce1b2bc760daf9cc07591bdc4d3e83e40391f468.camel@intel.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <ce1b2bc760daf9cc07591bdc4d3e83e40391f468.camel@intel.com>
Precedence: bulk

On Wed, Dec 14, 2022 at 10:51:31AM +0000,
"Huang, Kai" <kai.huang@intel.com> wrote:

> On Sat, 2022-10-29 at 23:22 -0700, isaku.yamahata@intel.com wrote:
> > From: Isaku Yamahata <isaku.yamahata@intel.com>
> > 
> > kvm_unmap_gfn_range() needs to know the reason of the callback for TDX.
> > mmu notifier, set memattr ioctl or restrictedmem notifier.  Based on the
> > reason, TDX changes the behavior.  For mmu notifier, it's the operation on
> > shared memory slot to zap shared PTE.  For set memattr, private<->shared
> > conversion, zap the original PTE.  For restrictedmem, it's a hint that TDX
> > can ignore.
> 
> Could you elaborate why restricted memfd notifier can be ignored? IIUC if
> userspace punch a hole, the pages within the hole will be de-allocated.  So why
> can such notifier be ignored?

Because set-memory-attribute ioctl is expected to follow the callback from
restrictedmem.  So set memory attributes can do de-allocation. I wanted to avoid
zapping twice.

With v9 UPM, the restrictedmem callback was triggered for both allocation and
punch-hole.
With v10 UPM, the callback is triggered only for punch-hole. With v10 callback
semantics, probably this can be cleaned up slightly.
-- 
Isaku Yamahata <isaku.yamahata@gmail.com>