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 6CB7EC54EBD for ; Mon, 9 Jan 2023 19:32:13 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id DA7628E0002; Mon, 9 Jan 2023 14:32:12 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id D576B8E0001; Mon, 9 Jan 2023 14:32:12 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id BD17E8E0002; Mon, 9 Jan 2023 14:32:12 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id A7B2D8E0001 for ; Mon, 9 Jan 2023 14:32:12 -0500 (EST) Received: from smtpin06.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id 83685120C0E for ; Mon, 9 Jan 2023 19:32:12 +0000 (UTC) X-FDA: 80336256504.06.F236CD5 Received: from mail-pf1-f171.google.com (mail-pf1-f171.google.com [209.85.210.171]) by imf14.hostedemail.com (Postfix) with ESMTP id C3B9C100010 for ; Mon, 9 Jan 2023 19:32:10 +0000 (UTC) Authentication-Results: imf14.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b=sOIFmmww; spf=pass (imf14.hostedemail.com: domain of seanjc@google.com designates 209.85.210.171 as permitted sender) smtp.mailfrom=seanjc@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=1673292730; 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=MS9c8pSDmVucTZdPdHhH3mdXKbPND6bL5OXnhsaz428=; b=IDIitiYFEZAtFfX5OAlHknBgo3aO70859cqHtbWSE+DRdKWa/BsMmQfmPPyAWY1szWym1b JU2jfXDtwr4Pr7J0JQ/5wyK+c/j19mOH/0l9O2A0n1VkPnpJPnPmeIPpZ6PScbfLCM8WsL JyavUBNfcaoMFWvfqYgtNgLw5Ml8OKc= ARC-Authentication-Results: i=1; imf14.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b=sOIFmmww; spf=pass (imf14.hostedemail.com: domain of seanjc@google.com designates 209.85.210.171 as permitted sender) smtp.mailfrom=seanjc@google.com; dmarc=pass (policy=reject) header.from=google.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1673292730; a=rsa-sha256; cv=none; b=MJD3x3sSdGEUKxUn2V5QSm3u78q+zjvoJapHEfEMT4wR3OXBxR465mws19WPZ68h7/RfdB YGtrRz9fQOH4J/S+Vi1S8rME9I6G6FSyvsBP7vEoJxqI0MzD2HLCQpfq5xAv0iekqqoaZF FmDmZ42xAgTUtyiALtZTSRI9fy++fEY= Received: by mail-pf1-f171.google.com with SMTP id 200so803020pfx.7 for ; Mon, 09 Jan 2023 11:32:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=MS9c8pSDmVucTZdPdHhH3mdXKbPND6bL5OXnhsaz428=; b=sOIFmmww5t87chNqg4RrjKvRSK55mbJUfkLlDwVdXFzdUVNQpuL8j+67d+DkgdzGV/ cY+1zKjyGAv7inACtQNgX5uUKu4ApW+iH+DVN7GkXfrRLLF2Mvo9WifnFmurzCTgdAvo yO0VsoKDonS/b5FpljJp4kIUzSG1uLseP8M04BYadiPR3LnDKhEB8JDIFZ6XY2cYQ9Ip q/lAxkFfWGCi4n140C5isaU+LhXs1upwAI92uUGwcJ28pRBl0VFZtoKmw+InBC55cTsl h4qHQp+F6duxw8RJ/SXhE+ei/WHcJpuK0DK+gQrpAmJlxVZpoBxyR4o9mafVKF6RyDWB AG3Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=MS9c8pSDmVucTZdPdHhH3mdXKbPND6bL5OXnhsaz428=; b=N2Idm2OQJNbGj7TjHrk/+2D1gU2NlZ9+1qH5QLdlnX6Bcuh/mqdg0NdaAT8Yuuf/ud sBQ3WaB4Kvo+cWFbSgE8YnCINLCiVZpmm4dsG0QlL67JTt9lKwllTx0EuDS7TMtf7v3f H+ZFEpiVwpJogPSS+NzWsWAnHx7JrBFBO8/OUJFu5Ur4Om+k1LQPyjsO5S5aUOfWtXJR fajN3CKOaOBgIln/G4svqmIVfUbPj6t0v4HqChiIY/dp2PHcf5afAcUB+rIFQEYarigg wVRIFZYUds6BPDIlNs4Ws/crsFzj7mgxSgZuN0BM3e3tWkFBZZADKBc9Evf6uHYbubWc 5DEQ== X-Gm-Message-State: AFqh2kpF3dz+5Mh47LWjPUeAp1Xql2Es/VFwgzj6gEgFCE+T1F/jzefN X75v0oNplQjzw2lmvi0fF/IThw== X-Google-Smtp-Source: AMrXdXsOvwNIYYmxRZ1A4P2qL2M11DO9ETy3xVnstT6ROBE9IIpgFgsb6iMlmsjwANei+MKsQQb7Fw== X-Received: by 2002:aa7:973c:0:b0:574:8995:c0d0 with SMTP id k28-20020aa7973c000000b005748995c0d0mr742042pfg.1.1673292729425; Mon, 09 Jan 2023 11:32:09 -0800 (PST) Received: from google.com (7.104.168.34.bc.googleusercontent.com. [34.168.104.7]) by smtp.gmail.com with ESMTPSA id 194-20020a6214cb000000b005809d382016sm6429041pfu.74.2023.01.09.11.32.08 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 09 Jan 2023 11:32:09 -0800 (PST) Date: Mon, 9 Jan 2023 19:32:05 +0000 From: Sean Christopherson To: Chao Peng Cc: Jarkko Sakkinen , kvm@vger.kernel.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org, linux-fsdevel@vger.kernel.org, linux-arch@vger.kernel.org, linux-api@vger.kernel.org, linux-doc@vger.kernel.org, qemu-devel@nongnu.org, Paolo Bonzini , Jonathan Corbet , Vitaly Kuznetsov , Wanpeng Li , Jim Mattson , Joerg Roedel , Thomas Gleixner , Ingo Molnar , Borislav Petkov , Arnd Bergmann , Naoya Horiguchi , Miaohe Lin , x86@kernel.org, "H . Peter Anvin" , Hugh Dickins , Jeff Layton , "J . Bruce Fields" , Andrew Morton , Shuah Khan , Mike Rapoport , Steven Price , "Maciej S . Szmigiero" , Vlastimil Babka , Vishal Annapurve , Yu Zhang , "Kirill A . Shutemov" , luto@kernel.org, jun.nakajima@intel.com, dave.hansen@intel.com, ak@linux.intel.com, david@redhat.com, aarcange@redhat.com, ddutile@redhat.com, dhildenb@redhat.com, Quentin Perret , tabba@google.com, Michael Roth , mhocko@suse.com, wei.w.wang@intel.com Subject: Re: [PATCH v10 3/9] KVM: Extend the memslot to support fd-based private memory Message-ID: References: <20221202061347.1070246-1-chao.p.peng@linux.intel.com> <20221202061347.1070246-4-chao.p.peng@linux.intel.com> <20230106094000.GA2297836@chaop.bj.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20230106094000.GA2297836@chaop.bj.intel.com> X-Rspam-User: X-Rspamd-Server: rspam04 X-Rspamd-Queue-Id: C3B9C100010 X-Stat-Signature: x8qaxbtuafcxwoyt8hw76ikjdg4gcfzi X-HE-Tag: 1673292730-305384 X-HE-Meta: U2FsdGVkX1+8TjzvzVKZW39RWjptMvqh0BxExZ1L9dU+13scBg9Zp95o3Iw18/LDNMLg9rkRg3lc4Ma+Gn4uclM2X0NZYBGbjxFwYnJdTvBR+5ZxlJP1U1uz/oJ5SJ+aqio27h/eQ4jbjR3hStiC/Q3I0UD900QGPr6J0b9E7ZldrNgprNjNJiVW0N6TGmahlsyTyIrDFPKd/+MYY3Up0xkg60if9rSnCqWeiq9KALx44wcGY0mBx8tdPNk6Q6UzeAm9STqMdwZ8GEXf8FeFeJs5mzuhKN5/YFVXxhw13GARaSY4vXiHi0mHidWqZrql9rr52cLBrih2mcu2qpiDnF4SYX13Dsp/RVnYFZrScP/4+bAip8thTs5U1AFrMJPFjp1c5t5BZ+E/+cVkGhr/rl4bbq3uzJBD+Q7pwaxAu8qUh4RSiuGvy8ixP448UJhDltX7sw2Yl1n8EvWGq8Lj2UXpmzJSinXqGSEr/JiwCJ9IGieUWN0f1lJEuqYYCSQxBGk/MMbIuT/LsCF4RakG34Hd42aDxGKMfHzPUO+IHl5SYY5hyMwOcSRLAy3HAY7qg+OV2o8zPt5ZviXhfsMbpvSgCDpLhDFrIHKcN6KzNNXXJqPmSyLjlVAfFsWJLsYxW2GQdbPfxIHw3sEcGRnWrhUNkV95sNbUiLkbGGhXGiLmc3j/3GNHSIOWzNPnklHAwcI8lk7yCqCZmxP7QwtGa4RErx/d6/J1hXMn3PcDkJmUYtxkPxDxzisgCRUt//z08g7Y2LwNEJgI/5nw+0qibQ1MEHmNuZDerDa4CO5sPzBKKLc3idIcGE7jDsBb8OU76Dkm+npxWAqtV2WCacQmTPsTPKZZpLAnhnD32RBOXmUQRmstkdIcyk8+tf7DqlZIqo4xiG+8IKC41xNe65sMllblkO4HT+aZTQF0LW77eu1Ct2haPmu1bCsIipWA2HPi1arHdSB0nawdHlk4ERA c1Soig/P QL5B+Wp6mf28u6eyME+evcY4LSys7qA4c3t2GIXd+nfgx2PXTwD9AycYOIn4GlS1n7Xu/tbcEKefG2sxzPT6dYUWs12/CxjQgmeva 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 Fri, Jan 06, 2023, Chao Peng wrote: > On Thu, Jan 05, 2023 at 11:23:01AM +0000, Jarkko Sakkinen wrote: > > On Fri, Dec 02, 2022 at 02:13:41PM +0800, Chao Peng wrote: > > > To make future maintenance easy, internally use a binary compatible > > > alias struct kvm_user_mem_region to handle both the normal and the > > > '_ext' variants. > > > > Feels bit hacky IMHO, and more like a completely new feature than > > an extension. > > > > Why not just add a new ioctl? The commit message does not address > > the most essential design here. > > Yes, people can always choose to add a new ioctl for this kind of change > and the balance point here is we want to also avoid 'too many ioctls' if > the functionalities are similar. The '_ext' variant reuses all the > existing fields in the 'normal' variant and most importantly KVM > internally can reuse most of the code. I certainly can add some words in > the commit message to explain this design choice. After seeing the userspace side of this, I agree with Jarkko; overloading KVM_SET_USER_MEMORY_REGION is a hack. E.g. the size validation ends up being bogus, and userspace ends up abusing unions or implementing kvm_user_mem_region itself. It feels absolutely ridiculous, but I think the best option is to do: #define KVM_SET_USER_MEMORY_REGION2 _IOW(KVMIO, 0x49, \ struct kvm_userspace_memory_region2) /* for KVM_SET_USER_MEMORY_REGION2 */ struct kvm_user_mem_region2 { __u32 slot; __u32 flags; __u64 guest_phys_addr; __u64 memory_size; __u64 userspace_addr; __u64 restricted_offset; __u32 restricted_fd; __u32 pad1; __u64 pad2[14]; } And it's consistent with other KVM ioctls(), e.g. KVM_SET_CPUID2. Regarding the userspace side of things, please include Vishal's selftests in v11, it's impossible to properly review the uAPI changes without seeing the userspace side of things. I'm in the process of reviewing Vishal's v2[*], I'll try to massage it into a set of patches that you can incorporate into your series. [*] https://lore.kernel.org/all/20221205232341.4131240-1-vannapurve@google.com