From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-2.3 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 048DDCA9EAE for ; Wed, 23 Oct 2019 05:41:37 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 8D7552173B for ; Wed, 23 Oct 2019 05:41:36 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 8D7552173B Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=linux.ibm.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id DBD916B0003; Wed, 23 Oct 2019 01:41:35 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id D45EE6B0006; Wed, 23 Oct 2019 01:41:35 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id C0D1B6B0007; Wed, 23 Oct 2019 01:41:35 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0198.hostedemail.com [216.40.44.198]) by kanga.kvack.org (Postfix) with ESMTP id 9966C6B0003 for ; Wed, 23 Oct 2019 01:41:35 -0400 (EDT) Received: from smtpin15.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay03.hostedemail.com (Postfix) with SMTP id 32145824999B for ; Wed, 23 Oct 2019 05:41:35 +0000 (UTC) X-FDA: 76073952150.15.board21_2ae5257cde90c X-HE-Tag: board21_2ae5257cde90c X-Filterd-Recvd-Size: 6364 Received: from mx0a-001b2d01.pphosted.com (mx0b-001b2d01.pphosted.com [148.163.158.5]) by imf10.hostedemail.com (Postfix) with ESMTP for ; Wed, 23 Oct 2019 05:41:34 +0000 (UTC) Received: from pps.filterd (m0098416.ppops.net [127.0.0.1]) by mx0b-001b2d01.pphosted.com (8.16.0.27/8.16.0.27) with SMTP id x9N5b1iw086012 for ; Wed, 23 Oct 2019 01:41:33 -0400 Received: from e06smtp02.uk.ibm.com (e06smtp02.uk.ibm.com [195.75.94.98]) by mx0b-001b2d01.pphosted.com with ESMTP id 2vtcnwxe5t-1 (version=TLSv1.2 cipher=AES256-GCM-SHA384 bits=256 verify=NOT) for ; Wed, 23 Oct 2019 01:41:33 -0400 Received: from localhost by e06smtp02.uk.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Wed, 23 Oct 2019 06:41:31 +0100 Received: from b06cxnps3075.portsmouth.uk.ibm.com (9.149.109.195) by e06smtp02.uk.ibm.com (192.168.101.132) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; (version=TLSv1/SSLv3 cipher=AES256-GCM-SHA384 bits=256/256) Wed, 23 Oct 2019 06:41:28 +0100 Received: from b06wcsmtp001.portsmouth.uk.ibm.com (b06wcsmtp001.portsmouth.uk.ibm.com [9.149.105.160]) by b06cxnps3075.portsmouth.uk.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id x9N5fQRs18546696 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 23 Oct 2019 05:41:26 GMT Received: from b06wcsmtp001.portsmouth.uk.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 9D012A405F; Wed, 23 Oct 2019 05:41:26 +0000 (GMT) Received: from b06wcsmtp001.portsmouth.uk.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 8E2C6A405B; Wed, 23 Oct 2019 05:41:24 +0000 (GMT) Received: from in.ibm.com (unknown [9.124.35.40]) by b06wcsmtp001.portsmouth.uk.ibm.com (Postfix) with ESMTPS; Wed, 23 Oct 2019 05:41:24 +0000 (GMT) Date: Wed, 23 Oct 2019 11:11:22 +0530 From: Bharata B Rao To: Paul Mackerras Cc: Bharata B Rao , linuxram@us.ibm.com, cclaudio@linux.ibm.com, kvm-ppc@vger.kernel.org, linux-mm@kvack.org, jglisse@redhat.com, Aneesh Kumar , paulus@au1.ibm.com, sukadev@linux.vnet.ibm.com, linuxppc-dev , Christoph Hellwig Subject: Re: [PATCH v9 2/8] KVM: PPC: Move pages between normal and secure memory Reply-To: bharata@linux.ibm.com References: <20190925050649.14926-1-bharata@linux.ibm.com> <20190925050649.14926-3-bharata@linux.ibm.com> <20191018030049.GA907@oak.ozlabs.ibm.com> <20191023041754.GA5809@oak.ozlabs.ibm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20191023041754.GA5809@oak.ozlabs.ibm.com> User-Agent: Mutt/1.12.1 (2019-06-15) X-TM-AS-GCONF: 00 x-cbid: 19102305-0008-0000-0000-00000325D9B5 X-IBM-AV-DETECTION: SAVI=unused REMOTE=unused XFE=unused x-cbparentid: 19102305-0009-0000-0000-00004A4507B7 Message-Id: <20191023054122.GA1295@in.ibm.com> X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:,, definitions=2019-10-23_01:,, signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 priorityscore=1501 malwarescore=0 suspectscore=2 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1908290000 definitions=main-1910230055 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Wed, Oct 23, 2019 at 03:17:54PM +1100, Paul Mackerras wrote: > On Tue, Oct 22, 2019 at 11:59:35AM +0530, Bharata B Rao wrote: > The mapping of pages in userspace memory, and the mapping of userspace > memory to guest physical space, are two distinct things. The memslots > describe the mapping of userspace addresses to guest physical > addresses, but don't say anything about what is mapped at those > userspace addresses. So you can indeed get a page fault on a > userspace address at the same time that a memslot is being deleted > (even a memslot that maps that particular userspace address), because > removing the memslot does not unmap anything from userspace memory, > it just breaks the association between that userspace memory and guest > physical memory. Deleting the memslot does unmap the pages from the > guest but doesn't unmap them from the userspace process (e.g. QEMU). > > It is an interesting question what the semantics should be when a > memslot is deleted and there are pages of userspace currently paged > out to the device (i.e. the ultravisor). One approach might be to say > that all those pages have to come back to the host before we finish > the memslot deletion, but that is probably not necessary; I think we > could just say that those pages are gone and can be replaced by zero > pages if they get accessed on the host side. If userspace then unmaps > the corresponding region of the userspace memory map, we can then just > forget all those pages with very little work. There are 5 scenarios currently where we are replacing the device mappings: 1. Guest reset 2. Memslot free (Memory unplug) (Not present in this version though) 3. Converting secure page to shared page 4. HV touching the secure page 5. H_SVM_INIT_ABORT hcall to abort SVM due to errors when transitioning to secure mode (Not present in this version) In the first 3 cases, we don't need to get the page to HV from the secure side and hence skip the page out. However currently we do allocate fresh page and replace the mapping with the new one. > > However if that sounds fragile, may be I can go back to my initial > > design where we weren't using rmap[] to store device PFNs. That will > > increase the memory usage but we give us an easy option to have > > per-guest mutex to protect concurrent page-ins/outs/faults. > > That sounds like it would be the best option, even if only in the > short term. At least it would give us a working solution, even if > it's not the best performing solution. Sure, will avoid using rmap[] in the next version. Regards, Bharata.