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 BA6A6CE7AB1 for ; Mon, 25 Sep 2023 17:37:48 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 0CF086B012D; Mon, 25 Sep 2023 13:37:48 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 07F856B012E; Mon, 25 Sep 2023 13:37:48 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id E61BC6B012F; Mon, 25 Sep 2023 13:37:47 -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 D7FF86B012D for ; Mon, 25 Sep 2023 13:37:47 -0400 (EDT) Received: from smtpin08.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id AE32C1603AB for ; Mon, 25 Sep 2023 17:37:46 +0000 (UTC) X-FDA: 81275827332.08.357DF60 Received: from mail-yb1-f201.google.com (mail-yb1-f201.google.com [209.85.219.201]) by imf14.hostedemail.com (Postfix) with ESMTP id D184F100012 for ; Mon, 25 Sep 2023 17:37:44 +0000 (UTC) Authentication-Results: imf14.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=qNduayaC; spf=pass (imf14.hostedemail.com: domain of 3Z8URZQYKCGgYKGTPIMUUMRK.IUSROTad-SSQbGIQ.UXM@flex--seanjc.bounces.google.com designates 209.85.219.201 as permitted sender) smtp.mailfrom=3Z8URZQYKCGgYKGTPIMUUMRK.IUSROTad-SSQbGIQ.UXM@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=1695663464; 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: in-reply-to:in-reply-to:references:references:dkim-signature; bh=4OSNJSuzGEyn2eFVxut8UHIn8mk8UoHB1vJTBDeWUjg=; b=QjnZNk0RxzF9TYDNz0Fa1+tQ4OofeV8tLQA9sLtO6CQrrXsNPD0tINebZhzvNV4DVv2k28 NWZKjEWol4PCAN5SvOTf/Z8OJX44hgKX7Kp4zzHJt4/OyefAtrclvcT+VBnTxZBw7FT/PC nN7iQJifEBDh/tbzPCE5ZzKeMK5JBCI= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1695663464; a=rsa-sha256; cv=none; b=VOG1qLjqAHLfbeM5CWA9+DCuaZ6C1Ll2QdMYneqjp2RMvW1oSDh3V+zWJqWSaH/CAeuz9l hSvl+UxNwd/iutiRnkXWN+mI4rJAxrhnZ4UydkwjYznqFUOiS8+c2lk2OCgXFyQBJYLKgO QBOt+nBJAQE/WH7xGJY9S1SL9e9Hl8U= ARC-Authentication-Results: i=1; imf14.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=qNduayaC; spf=pass (imf14.hostedemail.com: domain of 3Z8URZQYKCGgYKGTPIMUUMRK.IUSROTad-SSQbGIQ.UXM@flex--seanjc.bounces.google.com designates 209.85.219.201 as permitted sender) smtp.mailfrom=3Z8URZQYKCGgYKGTPIMUUMRK.IUSROTad-SSQbGIQ.UXM@flex--seanjc.bounces.google.com; dmarc=pass (policy=reject) header.from=google.com Received: by mail-yb1-f201.google.com with SMTP id 3f1490d57ef6-d817775453dso9995365276.2 for ; Mon, 25 Sep 2023 10:37:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1695663464; x=1696268264; darn=kvack.org; h=cc:to:from:subject:message-id:references:mime-version:in-reply-to :date:from:to:cc:subject:date:message-id:reply-to; bh=4OSNJSuzGEyn2eFVxut8UHIn8mk8UoHB1vJTBDeWUjg=; b=qNduayaCc7goZgGNKm7yP4QoQnQMHGn261eMuLR1ckainQsePckvuuYBxt2gwIth+v ikpe73PihJse5AQ5nxvzlC4Bylixa90Gj5IYDKydn3AxvUyQovTWmzrPLaDzCkU6TV0v /BOKK4UbXuSQtafHXAo1PLCPp+NKw4bNQCyTjGI4xUW/T12Z/zJRwM7XVKlB9SFJE8Tn UPr5xOsfjJrd7Q+RaGbTqdfHaHv4DBnJevDwZtrSxMAZBzVYxkAVRCaUi42FD/i871J9 0Xr0diytoI784sFAKgBr/WOuQQ2Xna26v+wqUYu42Js7hVoY+SfD/sdYW8ErcoZBB5eO lkdw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1695663464; x=1696268264; h=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=4OSNJSuzGEyn2eFVxut8UHIn8mk8UoHB1vJTBDeWUjg=; b=JouZ26eM4pVmEPMgjBG/WSXdj9LxEMwKaNDxwNsppfaahkrYFJKO+O3tDv2CSmQJ5G z3hOtCzv8plJ/mwMUIBvY0lJ1N2bYElXfGX9j8nTmGvysc8dz8Zi3F14xPf5NRhEMB9f 7y0u848jU3YjBy0HLuux6HdCs4MUc1Xx7P2ZmHiTfQsgjgsvkBULmV40/Fvb7t38OAKL cq9AfseWA+KqVvJ4moPiaq+GV3gYnP+4t1zzENjfevLeXIws821iwYl3yX8iovlif5Qb hieyifdOruppQcpvCP2FJVuS/e8LXvBKYQRW4HG3VZ6d041GBeKrDQbrniGEWA1gzq6Y LtuQ== X-Gm-Message-State: AOJu0YxrUwxIyOZfLmVj3OvOfeX+e4rtBqnT6Fh14ZpTcauVQVRvXsqE bu4X2gl3ziXAdHfhw3bb5KRdrSQKGzQ= X-Google-Smtp-Source: AGHT+IFbdNqdQBINXaKsxLFNsbPAlNsb64v79jTXlms6OpZDsyyWIMsDvfLKOISLOkUltg3c0KbHgHQxQwM= X-Received: from zagreus.c.googlers.com ([fda3:e722:ac3:cc00:7f:e700:c0a8:5c37]) (user=seanjc job=sendgmr) by 2002:a25:abac:0:b0:d81:fc08:29ea with SMTP id v41-20020a25abac000000b00d81fc0829eamr67094ybi.2.1695663463860; Mon, 25 Sep 2023 10:37:43 -0700 (PDT) Date: Mon, 25 Sep 2023 10:37:42 -0700 In-Reply-To: Mime-Version: 1.0 References: <20230914015531.1419405-1-seanjc@google.com> <20230914015531.1419405-12-seanjc@google.com> Message-ID: Subject: Re: [RFC PATCH v12 11/33] KVM: Introduce per-page memory attributes From: Sean Christopherson To: Yan Zhao 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@vger.kernel.org, linux-arm-kernel@lists.infradead.org, kvmarm@lists.linux.dev, linux-mips@vger.kernel.org, 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, linux-kernel@vger.kernel.org, Chao Peng , Fuad Tabba , 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="us-ascii" X-Rspamd-Queue-Id: D184F100012 X-Rspam-User: X-Rspamd-Server: rspam11 X-Stat-Signature: ui15bioa95fyhj9ez3y6j7jfu4n5rmuu X-HE-Tag: 1695663464-630593 X-HE-Meta: U2FsdGVkX19gNMPBJoevt7EbubOXLbnLL965ZgC64mK/74lIt74RaFzk94uqOz5mnBkQwnP6XPq7OSaL5Iz8qnaGbuHCGehDkfOplPh1dUs9cw+BvdcoRY8a0tsrvZ8qMcJ088G+dUQ2ze/8YTiPoziZ6tRyyZLfSqdUzc0hnKgv+dQzIKXTEwXj3Gqu2RoyfdAVnl8jZRvT+nMKaCKJrp9E1PMPnNYUpAD5lw2QRAikopeppp7/eUL6MHqHOyVjboTR+AYll4re3KuC+JbUHNAfbCWbW9TMRhILBOtGHOZ60cAwnLT3T/4mRRY9z7hOia/Ny3QaaL/Y+EU9/7YRwQiUOIHShUBRcYKkHHlAYh6vNasoL+3GZFMMTU5tqy4YG8RWskNe4mqblxLNzP4c63+3GTn4j8B2ynRsq3U3ypSdJVIYPB99rhZ2LVaOQmyhBHdIcnU73pzVsam6mWOWx2WvFUP4UHl8FyG3P8grSGsHWafW4nSwr7uqRH9hnZpmBVDDptDozSqMG24R264bWmCQg7LbTyxFzNwdQ5be2e8eWDtFtr30oHxD8MUeh+EVF7vXxHNg2J2MNwE6X9zTyPz6hsmLpjfwB6RKe1Q+ZFtlaQH24DDRnAvLY/YmvFzRuRMwSbyZPZRSQyAOGP+lmHqtmUW3sp5arvRKI8uawKVeqVOYqMqj6h+LCZ4pWkHCKtFGMRxCt+wZ4x0CXJFqxK4xtZK/awl4XGJs9GuWRVmX5ZX7Gf/HGEqXmyvMXC+zf1uI1+NzftWV4rLOelr4DGGXMwD0qFLI8o/o/g/NM/ZKkphSM5oZWenavK9c1gUMbEG1KL3wJFJvaXGsGlI+0Cz+VHfHD7fnu0BeHoiFAVy6He9hXk6YVkStYjE4Z2f68112ioB1xy6rxxtRVcPODXUr4Ifb59LJOT023eXjLemXMF8TH7/IYSibxwPW95C17L0Br6afZZ1RyfizNgL NxkfqWvM RU3mZveVsxGVDZZTAyNAHK2kYHbbny8eUo86cy9EzchJ1QiAaONFMpRpu4AqVmRjccCDMHXvF+Rvg1BUlt66Fo7pcOQGwmcJjOjp+tj5ucsu+K+jpkbTPCj2mV70/W8rSEXuArn2sl4DvNnYo6grU1Pjx9LYhe48DEmy0yX6rEI3QeEVtaylMhxZB0ZG8sOIZ6zgjThcz2MCixHHE9xKNR57SshY26+FyhL0mvzcDCuQ3INRO+upQ9neT4DLAJpv72EvX0qvhX5Cesn2ABRk9CTlLJ+SUl3RSrFGf61eZZT3DsGu6cISuhnuOBpI168Be14TxHGVcGRYjzF+2G23LfX9N2O6cplm/r5vb4Gu1vZ+96KLz0X1TWWdALNE1IR9CTzoLPZD04ika9ztLlv+Po0OOwKAEkEBK/hGUemfjyiz1nuc45dsaFGF2u4ugpH3AR/9QiORh5slmWmUwRdj7wytRtYNyjo/kqMFg4cQsVuGeIrlsoozoXXGML1zY5yzdyA/JcCQ0nrKWygxMXnXgHvqYj4ckWWud+3J779JhkzNWvoAjcNQhl0yqXj63I11LqV9UbpMEfr4yT1nk6xqCFPfy4smtfvb5YnBBBc9/qBF0CYUBPZgabpVDXvjWP3muvOfhcyhfGqaz4EtiI9TeexYT1WyfOz3PA0HR 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, Sep 21, 2023, Yan Zhao wrote: > On Wed, Sep 20, 2023 at 02:00:22PM -0700, Sean Christopherson wrote: > > On Fri, Sep 15, 2023, Yan Zhao wrote: > > > On Wed, Sep 13, 2023 at 06:55:09PM -0700, Sean Christopherson wrote: > > > > +/* Set @attributes for the gfn range [@start, @end). */ > > > > +static int kvm_vm_set_mem_attributes(struct kvm *kvm, gfn_t start, gfn_t end, > > > > + unsigned long attributes) > > > > +{ > > > > + struct kvm_mmu_notifier_range pre_set_range = { > > > > + .start = start, > > > > + .end = end, > > > > + .handler = kvm_arch_pre_set_memory_attributes, > > > > + .on_lock = kvm_mmu_invalidate_begin, > > > > + .flush_on_ret = true, > > > > + .may_block = true, > > > > + }; > > > > + struct kvm_mmu_notifier_range post_set_range = { > > > > + .start = start, > > > > + .end = end, > > > > + .arg.attributes = attributes, > > > > + .handler = kvm_arch_post_set_memory_attributes, > > > > + .on_lock = kvm_mmu_invalidate_end, > > > > + .may_block = true, > > > > + }; > > > > + unsigned long i; > > > > + void *entry; > > > > + int r = 0; > > > > + > > > > + entry = attributes ? xa_mk_value(attributes) : NULL; > > > Also here, do we need to get existing attributes of a GFN first ? > > > > No? @entry is the new value that will be set for all entries. This line doesn't > > touch the xarray in any way. Maybe I'm just not understanding your question. > Hmm, I thought this interface was to allow users to add/remove an attribute to a GFN > rather than overwrite all attributes of a GFN. Now I think I misunderstood the intention. > > But I wonder if there is a way for users to just add one attribute, as I don't find > ioctl like KVM_GET_MEMORY_ATTRIBUTES for users to get current attributes and then to > add/remove one based on that. e.g. maybe in future, KVM wants to add one attribute in > kernel without being told by userspace ? The plan is that memory attributes will be 100% userspace driven, i.e. that KVM will never add its own attributes. That's why there is (currently) no KVM_GET_MEMORY_ATTRIBUTES, the intended usage model is that userspace is fully responsible for managing attributes, and so should never need to query information that it already knows. If there's a compelling case for getting attributes then we could certainly add such an ioctl(), but I hope we never need to add a GET because that likely means we've made mistakes along the way. Giving userspace full control of attributes allows for a simpler uAPI, e.g. if userspace doesn't have full control, then setting or clearing bits requires a RMW operation, which means creating a more complex ioctl(). That's why its a straight SET operation and not an OR type operation.