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 067D6E92FDB for ; Fri, 6 Oct 2023 03:21:33 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id E65C394000F; Thu, 5 Oct 2023 23:21:20 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id D31A894000B; Thu, 5 Oct 2023 23:21:20 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id BA0DF94000F; Thu, 5 Oct 2023 23:21:20 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) by kanga.kvack.org (Postfix) with ESMTP id 9EFF394000B for ; Thu, 5 Oct 2023 23:21:20 -0400 (EDT) Received: from smtpin15.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id 7327A400B0 for ; Fri, 6 Oct 2023 03:21:20 +0000 (UTC) X-FDA: 81313585920.15.E9F55B0 Received: from mail-yw1-f201.google.com (mail-yw1-f201.google.com [209.85.128.201]) by imf23.hostedemail.com (Postfix) with ESMTP id 885D1140014 for ; Fri, 6 Oct 2023 03:21:18 +0000 (UTC) Authentication-Results: imf23.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=mrgqda7W; spf=pass (imf23.hostedemail.com: domain of 3LX0fZQYKCNQI40D926EE6B4.2ECB8DKN-CCAL02A.EH6@flex--seanjc.bounces.google.com designates 209.85.128.201 as permitted sender) smtp.mailfrom=3LX0fZQYKCNQI40D926EE6B4.2ECB8DKN-CCAL02A.EH6@flex--seanjc.bounces.google.com; dmarc=pass (policy=reject) header.from=google.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1696562478; 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=+GCfD3J/utVXt7fNFcXS7tndSxc76Lg25lhLquZNVGo=; b=L4qACd35TlbNYvciaMXwHKsjwvKKzqkJw0zMcvDXR8IeH/J14uYwQyv5LK3+4A0g2RH7xX kaAg5HPUwXBtkfWGmE/GS8e8dVtYPB37NQ45LfAPiUAJmURfHtr1zvVFWOtUUI4qD5tIGy ZaZ/ytNejhaoKYAKkzwbT7F7mU2o3Vc= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1696562478; a=rsa-sha256; cv=none; b=XBUNKo2V9+uEZgl3BPgvcolhhD3Ev+K8JXUJIf2iQkUsfa1A1BQDlRu+R9Gc0oyLpSO6d0 6b50iFKvxBoGZosX+VxinxF25GWEQIZjLrFYL3aGbctlO1oNhMR9jIOFUcFXgzw962HkF5 TNDxxnDYiyFCuEJLhCETFM/04zu2UcU= ARC-Authentication-Results: i=1; imf23.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=mrgqda7W; spf=pass (imf23.hostedemail.com: domain of 3LX0fZQYKCNQI40D926EE6B4.2ECB8DKN-CCAL02A.EH6@flex--seanjc.bounces.google.com designates 209.85.128.201 as permitted sender) smtp.mailfrom=3LX0fZQYKCNQI40D926EE6B4.2ECB8DKN-CCAL02A.EH6@flex--seanjc.bounces.google.com; dmarc=pass (policy=reject) header.from=google.com Received: by mail-yw1-f201.google.com with SMTP id 00721157ae682-59b59e1ac70so25289917b3.1 for ; Thu, 05 Oct 2023 20:21:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1696562477; x=1697167277; darn=kvack.org; h=content-transfer-encoding:cc:to:from:subject:message-id:references :mime-version:in-reply-to:date:from:to:cc:subject:date:message-id :reply-to; bh=+GCfD3J/utVXt7fNFcXS7tndSxc76Lg25lhLquZNVGo=; b=mrgqda7WEkDQkLZfdOmI6NPy7y1p0yU7WBNfd57Zjd7KUFut+yARjNloxLgjGDwMZm M04BlDiVPsy8nl0QpffTooCyvRh0VjiH3YGT4naqGrpKpyZHyq5NHwrcToVVltAzIWDN 2Q/h+y8TTi9Zt1V6GK6HWM1tQ51j5eEaxpxhDrd84a6rvpM3cVuz5s10jtylGYuQsiRC qEpYQt2IG/5RQ/iCms3jhM5DLyemREb0ziYg/efJo8u2k1w7i4gy4S751dplIHt3Sf7B 2gzv5gRYSnGOqnFf6TwpPpOAWKjjtCC/f4AYao1Hr0ybvwpKlLm+NTA8XZDz+oRMTJcl Wgbw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1696562477; x=1697167277; h=content-transfer-encoding:cc:to:from:subject:message-id:references :mime-version:in-reply-to:date:x-gm-message-state:from:to:cc:subject :date:message-id:reply-to; bh=+GCfD3J/utVXt7fNFcXS7tndSxc76Lg25lhLquZNVGo=; b=VBDg5dw5/3OVJPb6Nku2Ojkam5RTTr1sZ8o5QMLPbZlD2IzOBaVGeV+ZYqggSQrzif SraC+JM0MEaKEsYIXNIq1bPg3N1U8bsiMabMQglpYyOgqtth7iuzpcHvrfQgc2PDXu3D liy7Ydsx0g1xBj95wQNKt4suRmmpyXhThoPB7KHo3gh+9WqjKP4yXJfrVnwLQObIRc62 2uYyAPvtFYpJp6aWQE6zEg+2zwx1LelhgHV4qYpPYTaYT9BTzSuV23ygTHbzlGJEo4nw NOTQChHItZtTMO/Py0KSfbsR2r3MdbWvGtoqQuWp2QfvXHC0qK9aL1rmSUrMQWcd6tKq ai7A== X-Gm-Message-State: AOJu0YwNzj1rZf58P1X067kgfEvFgCA3kH0xSf82kv3IB9LTs9TC6epE FoP+SZOhuIZcNAifVrBqwn8bx2YwwoU= X-Google-Smtp-Source: AGHT+IHbgJX1dul2brLKqtxy3zNH4Wq8osuz6z+RCm0MrNAV7Qoo4mqOPY/NVTlIcosnwAkmq4EHKfjNEDc= X-Received: from zagreus.c.googlers.com ([fda3:e722:ac3:cc00:7f:e700:c0a8:5c37]) (user=seanjc job=sendgmr) by 2002:a25:ae41:0:b0:d78:a78:6fc7 with SMTP id g1-20020a25ae41000000b00d780a786fc7mr101904ybe.6.1696562477545; Thu, 05 Oct 2023 20:21:17 -0700 (PDT) Date: Thu, 5 Oct 2023 20:21:15 -0700 In-Reply-To: Mime-Version: 1.0 References: Message-ID: Subject: Re: [RFC PATCH v12 11/33] KVM: Introduce per-page memory attributes From: Sean Christopherson To: Fuad Tabba Cc: Paolo Bonzini , Marc Zyngier , Oliver Upton , Huacai Chen , Michael Ellerman , Anup Patel , Paul Walmsley , Palmer Dabbelt , Albert Ou , "Matthew Wilcox (Oracle)" , Andrew Morton , Paul Moore , James Morris , "Serge E. Hallyn" , KVM , "moderated list:ARM64 PORT (AARCH64 ARCHITECTURE)" , KVMARM , LinuxMIPS , linuxppc-dev@lists.ozlabs.org, kvm-riscv@lists.infradead.org, linux-riscv@lists.infradead.org, linux-fsdevel@vger.kernel.org, linux-mm@kvack.org, linux-security-module@vger.kernel.org, open list , Chao Peng , Jarkko Sakkinen , Anish Moorthy , Yu Zhang , Isaku Yamahata , Xu Yilun , Vlastimil Babka , Vishal Annapurve , Ackerley Tng , Maciej Szmigiero , David Hildenbrand , Quentin Perret , Michael Roth , Wang , Liam Merwick , Isaku Yamahata , "Kirill A . Shutemov" Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 885D1140014 X-Rspam-User: X-Rspamd-Server: rspam11 X-Stat-Signature: p4dxa9m73yp6dihip39ozbup5oub3s5z X-HE-Tag: 1696562478-818882 X-HE-Meta: U2FsdGVkX19tIzsEVzi7PfzuKGTVt8wVk+nTftSPm0Cu/hhcUmZWM5qCN9fF5mENbkj3fIuXGQVLfnDqJpWLACIesiTIfKNJit6HWGvqkaQFVJDURxPvnW7YYAendD2th7g07JdBGF1nrt0cQywWFdA0NiNMJjEVYocv8clq2buERUfYog61mnN2PnxGDDeg8n1r6FD6FWgUu+xGMHtz1Lmek1MJKca/t2X2mUTc9FDa6hYFUvUnPNydEwLGVxu69vFHGWzfed9F3/CBTL6EvJ4LEPcp917tAOT3rraRBMViESVh6voVRVkZNx5yCjLjAuONzTgWm/8FVWyM2t5L1Bd1aCNsdlHV3JVcoMYQfVQ6lqNE/UT6keZuXd+Mz20W1LhRdbCPKjy9z6ST/G6wu52vvd2ft3DQlUlpwOEUkIG4kHIRKQYOqRGWJz0LqNg1bnVfjb7u9G0kPQD6ehdvhDjDwsIFjU5XgYR4h5TlVwL+UfDQali8FeCwHrH3fdtHZE427qsS5XtHyNwJeJREyWxUvuUNZ6s5ERjIVLUDedkA9jygcsTJ+vhu4Rwli7TzzdEYZaCxU8TLKiSGNlHG+F7D0fF0MZXVLAzOJj2ja23AjefHreyY4XVYabsozPqNH3GGeQoIw/tE3Xf4znzrlEZQ/mwbxcgxVgTuOiTV9UFcDry0pnrlAMlyXwdCt63gOoEttf7o9SEQn3UBQgNznbbj5w2KnOGyHTFnkmvH8FzIPE4h83UAQduB4FOmMbqRWwFHDoegXL8wCpq5oJwivb8dR5SIZvyemYW5NdRH5ADVqsyJTEZQGQqDB+DCGlAw6m2cTOTZTWbxNXdA3be98N5EVo+IbsIno+oGVMRj1g/ZafFm6oSeaA6Danc6Fn5ESJz7dCmuzza5yHz4onHvvZdDzrTLZi3x7jLvU4prkmjSw9exxQRckazZLGkPPjjvAhcjOkEPd6/qYCmI09G fWQ2fnCo rk5RArUcGBEYeixT6BA9wHpQq7qtQKh9Z4nsclN+a+mmSq9vTXhA9dDdUVyrgX361SeAfuvD/jf5LHrmMCV3sgbfGGzjEQV3UkkDvP1sbabeQS2Ngx56ujybVyWBbCX1yIgFGXU7xHxchT9o2eVC93FyR1LCXdw5lx4U3+5n1iVm+k76ZwzUpvOoEWfa9RK8WfXdTTwESqX7oOETDU3//DMEDvZBI6QWlo9Bc8g68VJb64xJ4pjCfBFuiqH8VjE9rISxbsB+csxcb9REjyAVEZjfpKRa/BT42jjvSizOvlfG8HRutLPDw9/TKOyLYnj40MfT+TGnk7Yjw9HCqm1XyLkB/HEwMx+Hz5TGGANS9r756HPUohldpfgLfVkU42jXZHKQPb90XcsiLBUR802kllSVCimpOEUUfDXrsWcl24Ei7UrF+7PWOHkITIZy9OgNRA/7CLFDUbsIHCzHnYAY7C0jcoQNcOBRNnrBayePMxcvGE2ChP3SDkU03bMCsinQMeghdIu9fyC38dAQEDbXHrw5PwaTYEB7SIPjMgqXus3/3JxqLr4u7oXjRA3+TbDtf5frf6ZQv1b5O5ldNfnhDTXaCcfkMvM5vwUfNwnTLTdAtArvav2YcMsAwsobOrQ6j3hRmVE8D25JBYUmV2V79rr3aI2MAL7SvUSfGeXsrPzcJ6t+Go4HMP8agDw== 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 Thu, Oct 05, 2023, Fuad Tabba wrote: > Hi Sean, >=20 > On Tue, Oct 3, 2023 at 9:51=E2=80=AFPM Sean Christopherson wrote: > > > Like I said, pKVM doesn't need a userspace ABI for managing PRIVATE/S= HARED, > > > just a way of tracking in the host kernel of what is shared (as oppos= ed to > > > the hypervisor, which already has the knowledge). The solution could = simply > > > be that pKVM does not enable KVM_GENERIC_MEMORY_ATTRIBUTES, has its o= wn > > > tracking of the status of the guest pages, and only selects KVM_PRIVA= TE_MEM. > > > > At the risk of overstepping my bounds, I think that effectively giving = the guest > > full control over what is shared vs. private is a mistake. It more or = less locks > > pKVM into a single model, and even within that model, dealing with erro= rs and/or > > misbehaving guests becomes unnecessarily problematic. > > > > Using KVM_SET_MEMORY_ATTRIBUTES may not provide value *today*, e.g. the= userspace > > side of pKVM could simply "reflect" all conversion hypercalls, and term= inate the > > VM on errors. But the cost is very minimal, e.g. a single extra ioctl(= ) per > > converion, and the upside is that pKVM won't be stuck if a use case com= es along > > that wants to go beyond "all conversion requests either immediately suc= ceed or > > terminate the guest". >=20 > Now that I understand the purpose of KVM_SET_MEMORY_ATTRIBUTES, I > agree. However, pKVM needs to track at the host kernel (i.e., EL1) > whether guest memory is shared or private. Why does EL1 need it's own view/opinion? E.g. is it to avoid a accessing d= ata that is still private according to EL2 (on behalf of the guest)? Assuming that's the case, why can't EL1 wait until it gets confirmation fro= m EL2 that the data is fully shared before doing whatever it is that needs to be = done? Ah, is the problem that whether or not .mmap() is allowed keys off of the s= tate of the memory attributes? If that's so, then yeah, an internal flag in att= ributes is probably the way to go. It doesn't need to be a "host kernel private" f= lag though, e.g. an IN_FLUX flag to capture that the attributes aren't fully re= alized might be more intuitive for readers, and might have utility for other attri= butes in the future too. > One approach would be to add another flag to the attributes that > tracks the host kernel view. The way KVM_SET_MEMORY_ATTRIBUTES is > implemented now, userspace can zero it, so in that case, that > operation would need to be masked to avoid that. >=20 > Another approach would be to have a pKVM-specific xarray (or similar) > to do the tracking, but since there is a structure that's already > doing something similar (i.e.,the attributes array), it seems like it > would be unnecessary overhead. >=20 > Do you have any ideas or preferences? >=20 > Cheers, > /fuad