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 Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 71BBBEB64DD for ; Wed, 12 Jul 2023 08:36:03 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id BCF536B0071; Wed, 12 Jul 2023 04:36:02 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id B7E476B0072; Wed, 12 Jul 2023 04:36:02 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id A1F596B0075; Wed, 12 Jul 2023 04:36:02 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0013.hostedemail.com [216.40.44.13]) by kanga.kvack.org (Postfix) with ESMTP id 9301F6B0071 for ; Wed, 12 Jul 2023 04:36:02 -0400 (EDT) Received: from smtpin06.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id 4D5E2801E6 for ; Wed, 12 Jul 2023 08:36:02 +0000 (UTC) X-FDA: 81002302164.06.D6C5328 Received: from mx0b-001b2d01.pphosted.com (mx0b-001b2d01.pphosted.com [148.163.158.5]) by imf03.hostedemail.com (Postfix) with ESMTP id BD25B2000B for ; Wed, 12 Jul 2023 08:35:58 +0000 (UTC) Authentication-Results: imf03.hostedemail.com; dkim=pass header.d=ibm.com header.s=pp1 header.b=W8wCk4xv; dmarc=pass (policy=none) header.from=ibm.com; spf=pass (imf03.hostedemail.com: domain of imbrenda@linux.ibm.com designates 148.163.158.5 as permitted sender) smtp.mailfrom=imbrenda@linux.ibm.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1689150958; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=4wWvmE6riY6W/gEOwFAliD2QEWEyS8lb/MuEGAJ1j5o=; b=3k/I4VYT+NC0Kv2vpQ2upo8TN+2M7q6DfM8MoUgXz++q9FSNc1Tc0kp+U0Hqq1yKmDkIf+ DcVrUWFuedVAAbQTA47p/btAapY/Vdq7FBuQxOn3qSwajrokRwRbM5xjPHpWhQSKs9n2OO +BiTlFlCb1OSUWkYUXofdiFhCX0CYOU= ARC-Authentication-Results: i=1; imf03.hostedemail.com; dkim=pass header.d=ibm.com header.s=pp1 header.b=W8wCk4xv; dmarc=pass (policy=none) header.from=ibm.com; spf=pass (imf03.hostedemail.com: domain of imbrenda@linux.ibm.com designates 148.163.158.5 as permitted sender) smtp.mailfrom=imbrenda@linux.ibm.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1689150958; a=rsa-sha256; cv=none; b=RKkyqOmbDS/Ls4XdVBml0TU971mW8G4LbNFw5mVYfe76j/EVxs7XkmDoalsDmC3y4w+FUm jXV5OfVD0Lse1Mf3aa9rUfb1W/PXo8SMfo2n8km1804VistC3WbBOKaEY/N8ij++D2eqzq AOeujAvRbhmu03yUbhpQYvPtU6UPP30= Received: from pps.filterd (m0356516.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.17.1.19/8.17.1.19) with ESMTP id 36C8H6W5005418; Wed, 12 Jul 2023 08:35:52 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ibm.com; h=date : from : to : cc : subject : message-id : in-reply-to : references : mime-version : content-type : content-transfer-encoding; s=pp1; bh=4wWvmE6riY6W/gEOwFAliD2QEWEyS8lb/MuEGAJ1j5o=; b=W8wCk4xvkQn1//6F4lTivAknvJaZrparsug2om/MrAq7Cig1Q22gMS8yTPhnlhyk54bx rgO2PKLcJqRTO3ieRQzqcYyrZ15pQ+Pga9oA4OwuLJY+gTla14D3F0sFhj9bxPr5rFR1 +ikqwVe9ESkWm+4UrIZA9FXPZgm9wCEpDtEICqOUPrAErFZDoLxxFSZEc29iyV0c6c14 iIVWmi1vHOeqCayZIcm/4gMDqHccOGB1Ey5Ao4/h80/FLo102QRKrlFCb7+5+nJnQHcI FA9eHzbdDKpOaXH902yyT8qtYqF0YUkJJe15gJW2MxiGt98trsu4xg0rlIvHCKNX2BDz Vw== Received: from ppma04fra.de.ibm.com (6a.4a.5195.ip4.static.sl-reverse.com [149.81.74.106]) by mx0a-001b2d01.pphosted.com (PPS) with ESMTPS id 3rsrh80fb4-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 12 Jul 2023 08:35:51 +0000 Received: from pps.filterd (ppma04fra.de.ibm.com [127.0.0.1]) by ppma04fra.de.ibm.com (8.17.1.19/8.17.1.19) with ESMTP id 36C6akB3008911; Wed, 12 Jul 2023 08:35:49 GMT Received: from smtprelay02.fra02v.mail.ibm.com ([9.218.2.226]) by ppma04fra.de.ibm.com (PPS) with ESMTPS id 3rpye59u22-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 12 Jul 2023 08:35:49 +0000 Received: from smtpav01.fra02v.mail.ibm.com (smtpav01.fra02v.mail.ibm.com [10.20.54.100]) by smtprelay02.fra02v.mail.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id 36C8ZkP727067074 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 12 Jul 2023 08:35:46 GMT Received: from smtpav01.fra02v.mail.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id EB8222004D; Wed, 12 Jul 2023 08:35:45 +0000 (GMT) Received: from smtpav01.fra02v.mail.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id A122E2004B; Wed, 12 Jul 2023 08:35:45 +0000 (GMT) Received: from p-imbrenda (unknown [9.152.224.66]) by smtpav01.fra02v.mail.ibm.com (Postfix) with ESMTP; Wed, 12 Jul 2023 08:35:45 +0000 (GMT) Date: Wed, 12 Jul 2023 10:35:43 +0200 From: Claudio Imbrenda To: Matthew Wilcox Cc: Christian Borntraeger , Andrew Morton , linux-arch@vger.kernel.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org, Gerald Schaefer , linux-s390 Subject: Re: [PATCH v5 00/38] New page table range API Message-ID: <20230712103543.4304235c@p-imbrenda> In-Reply-To: References: <20230710204339.3554919-1-willy@infradead.org> <8cfc3eef-e387-88e1-1006-2d7d97a09213@linux.ibm.com> <20230711172440.77504856@p-imbrenda> Organization: IBM X-Mailer: Claws Mail 4.1.1 (GTK 3.24.38; x86_64-redhat-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-TM-AS-GCONF: 00 X-Proofpoint-GUID: BaW4a-jtxRC0PTUlpLFwd8HG0wdDW65g X-Proofpoint-ORIG-GUID: BaW4a-jtxRC0PTUlpLFwd8HG0wdDW65g X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.254,Aquarius:18.0.957,Hydra:6.0.591,FMLib:17.11.176.26 definitions=2023-07-12_05,2023-07-11_01,2023-05-22_02 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 clxscore=1015 mlxlogscore=937 suspectscore=0 lowpriorityscore=0 malwarescore=0 bulkscore=0 phishscore=0 impostorscore=0 priorityscore=1501 mlxscore=0 adultscore=0 spamscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2305260000 definitions=main-2307120070 X-Rspamd-Server: rspam09 X-Rspamd-Queue-Id: BD25B2000B X-Stat-Signature: ypopsi66an54a584z7jciinsptd9i7gf X-Rspam-User: X-HE-Tag: 1689150958-648781 X-HE-Meta: U2FsdGVkX190HCXv0O4t34c20EwZ4z+WfocUYv3FxHfT7i2UbqV4kwNcypq8zon5dv2TKELRmmDodJ5+WtFd4fMov7oAw1F3WS4diat1i+TztV6JDMxUAUfS4sgP+LX+4Cm6rRop1vdQDkKqGCtUL15sBo7aDQBkFv6DRQT8ENTuRvyteCuEf3ux4d53hvkLTEVYEjUoC8QOcTolb+8AOrtCGfaZqIze+IZe3igedc0swifYY+3vVnqLP+JsgTGQSpSTbYChQhQEa5mGDomZplvnPWU21sZiHTGnpym57SduFlW3pnKu2AtCloCV17apGT/Sk5nLyfmbnpZ7T76j/HkHfLyxuSN7stUhhVx31RyKjf/DjgGEiVqTD66j9OwyYlk8OToNBhNfxJYG9d4p6FZ5733sp9jpyXEaXk4ClWOAU0lsrGwSNLBPc++3Pcor0jmvztH58kmqGsCzXsFO3q1MwTLbbSVio78/YkQdT67SOzCy8cTLvpKRyMfbvLNzfnb6zLjScnAhjxIcwHp6npcTJUDrPNVcPgpVmLr51JI9D6d9MzzcIxz5F2mFV0BQ6eyqe5wFRZCrSaAxHMT9v1X3E8mSe3oNlTmfXh0CkgC4aqbnoNUFCN/JhqyrD8x7FTdKRMbJS5CpXCKZbuZIEBtSH4tWKxlbx5eWV7GUyHuFy2zkWhkVJzuYoZXU7qAmJje/wnLCgBpWe74gYkYr84pPNYSJEsUhfb2ceG4qAQBoWvSCyv2BrxkpuvRV5yNTz5dXtruWqmXacBjU2+c4ciTt6zqDvZOIRKXNev+Wp/CfJL/93fJpHODf3kaYbHf//xROIezRQ4pFom3+HzQ4xlZV4BWthwL8jADCeyy8vga1Ef8akoNwyftovbiEAJMuA+ZNxg5s49X/xmj8RzJ6199oCRpsJnuxqxdmrJMrllsbpqoZlCDYy2V2nRIRRMv535+LLGSp9VXHTjIYLaM I5kH1b0Q J7dfgPtG9zQ+pwWpnCxp9he/Pke+aLqgEasCIcYpZ65sFItD+VkavhvvYV5enTTOWk4V0bUYB3YpnHrSSOD83w7eV+GMIdBLNj02DuyIOQ1JABpU9+CrJCZEhMbhI8rFAi/8ljrIqdxo2UX1wKcjMvocWWmFmlCyOsAUUFUMnTFuDjgdpIQatGJHOImlpIdJnkzgEsWXHil8Rgw6njWT+HFUWhk9oSAO5eHRd 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, 12 Jul 2023 06:29:21 +0100 Matthew Wilcox wrote: > On Tue, Jul 11, 2023 at 05:24:40PM +0200, Claudio Imbrenda wrote: > > On Tue, 11 Jul 2023 13:36:27 +0100 > > Matthew Wilcox wrote: > > > > I think we do use PG_arch_1 on s390 for our secure page handling and > > > > making this perf folio instead of physical page really seems wrong > > > > and it probably breaks this code. > > > > > > Per-page flags are going away in the next few years, so you're going to > > > > For each 4k physical page frame, we need to keep track whether it is > > secure or not. > > Do you? Wouldn't it make more sense to track that per allocation instead no > of per page? ie if we allocate a 16kB anon folio for a VMA, don't you > want the entire folio to be marked as secure vs insecure? if we allocate a 16k folio, it would actually be initially marked as non-secure until the guest touches any of it, then only those 4k pages that are needed get marked as secure. the guest can also share the pages with the host, in which case the individual 4k pages get marked as non-secure once I/O is attempted on them (e.g. direct I/O) userspace (i.e. QEMU) can also try to look into the guest, causing individual pages to be exported (securely encrypted and then marked as non-secure) if they were secure and not shared. I/O cannot trigger exports, it will just fail, and that should not happen because in some cases it can bring down the whole system. Which is one of the main reasons why we need to keep track of the state. > > I don't really know what secure means in this context. I think it has > something to do with which of the VM or the hypervisor can access it, but > it feels like something new that I've never had properly explained to me. Secure means it belongs to a secure guest (confidential VM, protected virtualisation, Secure Execution, there are many names...). Hardware will prevent the host (or any other entity except for the secure guest itself) from accessing those 4k physical page frames, regardless of how the host might try. An exception will be presented for any attempts. I/O will not trigger any exception, and will instead just fail. I hope this explains why we need to track the property for each 4k physical page frame. > > > A bit in struct page seems the most logical choice. If that's not > > possible anymore, how would you propose we should do? > > The plan is to shrink struct page down to a single pointer (which interesting > includes a few tag bits to say what type that pointer is -- a page > table, anon mem, file mem, slab, etc). So there won't be any bits > available for something like "secure or not". You could use a side > structure if you really need to keep track on a per page basis. I guess that's something we will need to work on