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;
Date:   Mon, 11 Feb 2019 12:48:35 -0500
From:   "Michael S. Tsirkin" <mst@redhat.com>
To:     Dave Hansen <dave.hansen@intel.com>
Cc:     Alexander Duyck <alexander.duyck@gmail.com>, linux-mm@kvack.org,
        linux-kernel@vger.kernel.org, kvm@vger.kernel.org,
        rkrcmar@redhat.com, alexander.h.duyck@linux.intel.com,
        x86@kernel.org, mingo@redhat.com, bp@alien8.de, hpa@zytor.com,
        pbonzini@redhat.com, tglx@linutronix.de, akpm@linux-foundation.org
Subject: Re: [RFC PATCH 2/4] kvm: Add host side support for free memory hints
Message-ID: <20190211124203-mutt-send-email-mst@kernel.org>
References: <20190204181118.12095.38300.stgit@localhost.localdomain>
 <20190204181546.12095.81356.stgit@localhost.localdomain>
 <20190209194108-mutt-send-email-mst@kernel.org>
 <39c915a7-e317-db01-0286-579230f37da2@intel.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <39c915a7-e317-db01-0286-579230f37da2@intel.com>
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

On Mon, Feb 11, 2019 at 09:41:19AM -0800, Dave Hansen wrote:
> On 2/9/19 4:44 PM, Michael S. Tsirkin wrote:
> > So the policy should not leak into host/guest interface.
> > Instead it is better to just keep the pages pinned and
> > ignore the hint for now.
> 
> It does seems a bit silly to have guests forever hinting about freed
> memory when the host never has a hope of doing anything about it.
> 
> Is that part fixable?


Yes just not with existing IOMMU APIs.

It's in the paragraph just above that you cut out:
	Yes right now assignment is not smart enough but generally
	you can protect the unused page in the IOMMU and that's it,
	it's safe.

So e.g.
	extern int iommu_remap(struct iommu_domain *domain, unsigned long iova,
				     phys_addr_t paddr, size_t size, int prot);


I can elaborate if you like but generally we would need an API that
allows you to atomically update a mapping for a specific page without
perturbing the mapping for other pages.

-- 
MST