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:36:55 -0500
From:   "Michael S. Tsirkin" <mst@redhat.com>
To:     Alexander Duyck <alexander.h.duyck@linux.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, 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: <20190211123638-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>
 <96285ed154dbb92686ca0068e21f5e0500bb1ce7.camel@linux.intel.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <96285ed154dbb92686ca0068e21f5e0500bb1ce7.camel@linux.intel.com>
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

On Mon, Feb 11, 2019 at 09:34:25AM -0800, Alexander Duyck wrote:
> On Sat, 2019-02-09 at 19:44 -0500, Michael S. Tsirkin wrote:
> > On Mon, Feb 04, 2019 at 10:15:46AM -0800, Alexander Duyck wrote:
> > > From: Alexander Duyck <alexander.h.duyck@linux.intel.com>
> > > 
> > > Add the host side of the KVM memory hinting support. With this we expose a
> > > feature bit indicating that the host will pass the messages along to the
> > > new madvise function.
> > > 
> > > This functionality is mutually exclusive with device assignment. If a
> > > device is assigned we will disable the functionality as it could lead to a
> > > potential memory corruption if a device writes to a page after KVM has
> > > flagged it as not being used.
> > 
> > I really dislike this kind of tie-in.
> > 
> > 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 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.
> 
> Okay, I can do that. It also gives me a means of benchmarking just the
> hypercall cost versus the extra page faults and zeroing.

Good point. Same goes for poisoning :)