From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-delivery-1.mimecast.com ([207.211.31.120]:52507 "EHLO us-smtp-1.mimecast.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1726952AbgBTMPX (ORCPT ); Thu, 20 Feb 2020 07:15:23 -0500 Subject: Re: [PATCH v3 01/37] mm:gup/writeback: add callbacks for inaccessible pages References: <20200220104020.5343-1-borntraeger@de.ibm.com> <20200220104020.5343-2-borntraeger@de.ibm.com> From: David Hildenbrand Message-ID: Date: Thu, 20 Feb 2020 13:15:05 +0100 MIME-Version: 1.0 In-Reply-To: <20200220104020.5343-2-borntraeger@de.ibm.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable Sender: linux-s390-owner@vger.kernel.org List-ID: To: Christian Borntraeger , Janosch Frank , Andrew Morton Cc: KVM , Cornelia Huck , Thomas Huth , Ulrich Weigand , Claudio Imbrenda , linux-s390 , Michael Mueller , Vasily Gorbik , Andrea Arcangeli , linux-mm@kvack.org, Will Deacon On 20.02.20 11:39, Christian Borntraeger wrote: > From: Claudio Imbrenda >=20 > With the introduction of protected KVM guests on s390 there is now a > concept of inaccessible pages. These pages need to be made accessible > before the host can access them. >=20 > While cpu accesses will trigger a fault that can be resolved, I/O > accesses will just fail. We need to add a callback into architecture > code for places that will do I/O, namely when writeback is started or > when a page reference is taken. >=20 > This is not only to enable paging, file backing etc, it is also > necessary to protect the host against a malicious user space. For > example a bad QEMU could simply start direct I/O on such protected > memory. We do not want userspace to be able to trigger I/O errors and > thus we the logic is "whenever somebody accesses that page (gup) or > doing I/O, make sure that this page can be accessed. When the guest > tries to access that page we will wait in the page fault handler for > writeback to have finished and for the page_ref to be the expected > value. Subject: "mm: gup..." And I'd probably add that on s390x, it's unlikely to ever return !0. (why the WARN_ON is okay and has to be tackled once relevant) >=20 > Signed-off-by: Claudio Imbrenda > Acked-by: Will Deacon > Signed-off-by: Christian Borntraeger Reviewed-by: David Hildenbrand --=20 Thanks, David / dhildenb