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 C292EC4332F for ; Fri, 18 Nov 2022 15:59:21 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 9A82D6B0072; Fri, 18 Nov 2022 10:59:20 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 9584E6B0073; Fri, 18 Nov 2022 10:59:20 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 7F8BB8E0001; Fri, 18 Nov 2022 10:59:20 -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 6F0D96B0072 for ; Fri, 18 Nov 2022 10:59:20 -0500 (EST) Received: from smtpin10.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id 0A6EA1A0A0E for ; Fri, 18 Nov 2022 15:59:20 +0000 (UTC) X-FDA: 80147022480.10.DA3FE6E Received: from mail-pj1-f47.google.com (mail-pj1-f47.google.com [209.85.216.47]) by imf01.hostedemail.com (Postfix) with ESMTP id DD70840002 for ; Fri, 18 Nov 2022 15:59:17 +0000 (UTC) Received: by mail-pj1-f47.google.com with SMTP id h14so4857711pjv.4 for ; Fri, 18 Nov 2022 07:59:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:references:message-id:subject:cc:to:from:date:from:to :cc:subject:date:message-id:reply-to; bh=BIzAKlqfAaMg368D6jPlp8HmIeVCVtTOFRZVfOrIoRA=; b=s6eyQMrxXlVr7mjyTTlqJhnlh/Xi9X6Am4TwNlENwsPyRh8KvXIqhnsP3MMWC9+MoB oQd97BmjUOsQPxgMsh5zyjcOYLIVp3cqB3U8qN7/Ud5hvTdIANRIWIS/vJblpoBTxukB h0Lxk6Jg3vNqw4OVzI0CkcjluXS6vsT31cdyDImlVx7++g13+ozmNNZ5BkzVdivrg7g+ 00m3rpeYDbyzY05rk/dB8GnC4ClchfIxtJ5aTCzCQyATv7KhMjKNSIDvnh3cGt1Q5v+L lNMyGoelDxkjB2wAw8ywO8jmucxwhUGJpJ8n7dWOAqcgUj06ocsZtkUfpHvBn0wBdFz1 TsrA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=in-reply-to:content-transfer-encoding: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=BIzAKlqfAaMg368D6jPlp8HmIeVCVtTOFRZVfOrIoRA=; b=W3VhvlYU6FGsYwNL9Q6hz3B1/sMwV14dxenDrIZhmdNXY0KTgEGULPlYLFVWF/7l+N yvtv3skGUpYyXuL91vYb24Ro9P8DBvIXD4xsrPjlK9iKj15OSkFDTd6k+g/6jTpqStPn cgcoLDT99lZQXCQYU8zT+3FmrMEcwM1JHva9rLz6mGcgvTJdcHHgEoDh+tNgZtsHQm/+ ecetrSaW053ARKq/xxYsarrN72GG6fGlElq4EWqfrPwEkGM2y+saQfu7ooAnS+WZxvOj +GCZnST7bRurNHqYfEoiHqnq4JVA0vrdiIpHLSYGufY7Q6dWrTZaEDfivSaQTKOqMGsS kLAg== X-Gm-Message-State: ANoB5pkIcjmj8/EVCVuXiyIi3EfuzgYvbZL0OVqP1XqkhNChJlAfY57U ZJu+lHEQDBn8ydC9YiyGAuJSDg== X-Google-Smtp-Source: AA0mqf68z73TZ4LH+iMU8Y7+vIcozkzW9+xI2VfYzqSxI4RUtQBXAdSaqw03S7HKwO0upOzd1Ydjhw== X-Received: by 2002:a17:90a:9f03:b0:211:59c6:6133 with SMTP id n3-20020a17090a9f0300b0021159c66133mr8428311pjp.238.1668787156611; Fri, 18 Nov 2022 07:59:16 -0800 (PST) Received: from google.com (7.104.168.34.bc.googleusercontent.com. [34.168.104.7]) by smtp.gmail.com with ESMTPSA id s16-20020a170902a51000b001869f2120a5sm3840359plq.34.2022.11.18.07.59.15 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 18 Nov 2022 07:59:16 -0800 (PST) Date: Fri, 18 Nov 2022 15:59:12 +0000 From: Sean Christopherson To: Alex =?iso-8859-1?Q?Benn=E9e?= Cc: Chao Peng , 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 , 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, Muchun Song , wei.w.wang@intel.com Subject: Re: [PATCH v9 3/8] KVM: Add KVM_EXIT_MEMORY_FAULT exit Message-ID: References: <20221025151344.3784230-1-chao.p.peng@linux.intel.com> <20221025151344.3784230-4-chao.p.peng@linux.intel.com> <87cz9o9mr8.fsf@linaro.org> <20221116031441.GA364614@chaop.bj.intel.com> <87mt8q90rw.fsf@linaro.org> <20221117134520.GD422408@chaop.bj.intel.com> <87a64p8vof.fsf@linaro.org> <20221118013201.GA456562@chaop.bj.intel.com> <87o7t475o7.fsf@linaro.org> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <87o7t475o7.fsf@linaro.org> ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1668787158; a=rsa-sha256; cv=none; b=STK302rihhxtZaJHdLGIhCh4BlI5DxNTWNQBZEk3fK55OF6dH6NIqsLvuu8uWSBMAIwnkM sV4bTZFENBrrkfi4MRenUbrczBfzs6dlI+X/q1GIXMANc+vmWM57bSZbD/awc4bcQ3KIXy 7eYGr88As82KyPxUf8VM4mjGq55zvxs= ARC-Authentication-Results: i=1; imf01.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b=s6eyQMrx; spf=pass (imf01.hostedemail.com: domain of seanjc@google.com designates 209.85.216.47 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=1668787158; 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=BIzAKlqfAaMg368D6jPlp8HmIeVCVtTOFRZVfOrIoRA=; b=iRGdp0pLEdesCQYdcoZhxctzKMwgoQ+UAYbaVq9BvodVt1MFQhu4XOuV0AXIEbY95hdYrN LFmmH2tvTrIxzhMrsYOPAlzfYL+ZdOkteveVfUzGDOwmBIxLA0pctgPMl72JGX39vaEyF7 VFTVfWqHlcHSouOvARDXcXTtaUFVHI8= X-Stat-Signature: yopmk6c3di4cba7ikkyw6yhrrwbfx41r X-Rspamd-Queue-Id: DD70840002 Authentication-Results: imf01.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b=s6eyQMrx; spf=pass (imf01.hostedemail.com: domain of seanjc@google.com designates 209.85.216.47 as permitted sender) smtp.mailfrom=seanjc@google.com; dmarc=pass (policy=reject) header.from=google.com X-Rspamd-Server: rspam04 X-Rspam-User: X-HE-Tag: 1668787157-765720 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, Nov 18, 2022, Alex Bennée wrote: > > Chao Peng writes: > > > On Thu, Nov 17, 2022 at 03:08:17PM +0000, Alex Bennée wrote: > >> >> I think this should be explicit rather than implied by the absence of > >> >> another flag. Sean suggested you might want flags for RWX failures so > >> >> maybe something like: > >> >> > >> >> KVM_MEMORY_EXIT_SHARED_FLAG_READ (1 << 0) > >> >> KVM_MEMORY_EXIT_SHARED_FLAG_WRITE (1 << 1) > >> >> KVM_MEMORY_EXIT_SHARED_FLAG_EXECUTE (1 << 2) > >> >> KVM_MEMORY_EXIT_FLAG_PRIVATE (1 << 3) > >> > > >> > Yes, but I would not add 'SHARED' to RWX, they are not share memory > >> > specific, private memory can also set them once introduced. > >> > >> OK so how about: > >> > >> KVM_MEMORY_EXIT_FLAG_READ (1 << 0) > >> KVM_MEMORY_EXIT_FLAG_WRITE (1 << 1) > >> KVM_MEMORY_EXIT_FLAG_EXECUTE (1 << 2) > >> KVM_MEMORY_EXIT_FLAG_SHARED (1 << 3) > >> KVM_MEMORY_EXIT_FLAG_PRIVATE (1 << 4) > > > > We don't actually need a new bit, the opposite side of private is > > shared, i.e. flags with KVM_MEMORY_EXIT_FLAG_PRIVATE cleared expresses > > 'shared'. > > If that is always true and we never expect a 3rd type of memory that is > fine. But given we are leaving room for expansion having an explicit bit > allows for that as well as making cases of forgetting to set the flags > more obvious. Hrm, I'm on the fence. A dedicated flag isn't strictly needed, e.g. even if we end up with 3+ types in this category, the baseline could always be "private". I do like being explicit, and adding a PRIVATE flag costs KVM practically nothing to implement and maintain, but evetually we'll up with flags that are paired with an implicit state, e.g. see the many #PF error codes in x86. In other words, inevitably KVM will need to define the default/base state of the access, at which point the base state for SHARED vs. PRIVATE is "undefined". The RWX bits are in the same boat, e.g. the READ flag isn't strictly necessary. I was thinking more of the KVM_SET_MEMORY_ATTRIBUTES ioctl(), which does need the full RWX gamut, when I typed out that response. So I would say if we add an explicit READ flag, then we might as well add an explicit PRIVATE flag too. But if we omit PRIVATE, then we should omit READ too.