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 88C33C4332F for ; Fri, 18 Nov 2022 13:28:44 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id DE9086B0071; Fri, 18 Nov 2022 08:28:43 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id D71EE6B0072; Fri, 18 Nov 2022 08:28:43 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id BEBAC8E0001; Fri, 18 Nov 2022 08:28:43 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id AAFE86B0071 for ; Fri, 18 Nov 2022 08:28:43 -0500 (EST) Received: from smtpin19.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id 6E232161321 for ; Fri, 18 Nov 2022 13:28:43 +0000 (UTC) X-FDA: 80146642926.19.0D628B5 Received: from mail-wr1-f47.google.com (mail-wr1-f47.google.com [209.85.221.47]) by imf30.hostedemail.com (Postfix) with ESMTP id E182C80008 for ; Fri, 18 Nov 2022 13:28:42 +0000 (UTC) Received: by mail-wr1-f47.google.com with SMTP id l14so9309555wrw.2 for ; Fri, 18 Nov 2022 05:28:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=content-transfer-encoding:mime-version:message-id:in-reply-to:date :subject:cc:to:from:user-agent:references:from:to:cc:subject:date :message-id:reply-to; bh=jFuAN0qalS8PXGclZBpJGpqKwSse98B1zaIXuj/qhsM=; b=X/gqqsl/WLpKtb9vOD4WiP4Oi7fWHjwjntx8mX7OxhsG5wzq+ZEu37/nMAgR/K0NTa w3qxyDj/5ysz05YJVpUs55kmmloX1IkC2zB1+/KzU94RHSvVV8QJIGUQUlri/5EUyK2r mGh3S7znVf5hxcm2FIq10hXZNhSXHhkk0XSUejjdU6tvjBJaDulCkhJ1yHJ5qUwTLhSd MoeZaDkThsztpF4G73yNPcJGkFAhdKPv1GGINAnUYMuW1RHIMFNHAh629fNId0Ygj6h4 QlGc8/i2b3sseFW3mxLr72CnhypCMQDx+K68Ypw8eLM56TGZBoLoX2zeC77yyHo3GfeR z9tg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:mime-version:message-id:in-reply-to:date :subject:cc:to:from:user-agent:references:x-gm-message-state:from:to :cc:subject:date:message-id:reply-to; bh=jFuAN0qalS8PXGclZBpJGpqKwSse98B1zaIXuj/qhsM=; b=U/KZ8zgBT0HJGTgcQmCIxSRv/Qs4m88vx9w5LUosRP+J09XXOxtvfoZl0J2uyLijNx UqfJSxDu6/7gkRjZgfDFTY58wgYOz5FaQffxix4FMkr/l8wRE3ztF6cTAoVoK9YAqx9/ 9lMjz8n6K98BgtiURNahrEFNdniPblUz9LzAakkOiRkIQfalgovqsfMOiN6CV5l6yDui P5vGxWrBJ9r6ROZergzo+sDhaDbxJBWGrg9ydhjQC1GZD9Spqtq30b1y9EzH5YN+EGln Er0HjQA1upaHE9CXPXPFJmcsCa8NTIgXdyXp0Sdgr+ULccDOP3YiLA90eCwInv0vAxn7 PwVQ== X-Gm-Message-State: ANoB5pl2tRknyDLL/W6bpq3xuV8/jvYuUpJawKriujiiyKf5Z1+U3/cj DPXj+QgiEZP1lRxR2bTdU306wQ== X-Google-Smtp-Source: AA0mqf6tYbIf5kiwBxBEeJpBK3Zoi0R3hbVIR4uxKZjI5EAk4XwJowCkhnyQfuyrbXxeKsj5OY9J7w== X-Received: by 2002:adf:aa91:0:b0:241:b2b2:a71d with SMTP id h17-20020adfaa91000000b00241b2b2a71dmr4389646wrc.326.1668778121454; Fri, 18 Nov 2022 05:28:41 -0800 (PST) Received: from zen.linaroharston ([185.81.254.11]) by smtp.gmail.com with ESMTPSA id y10-20020adfe6ca000000b00236860e7e9esm3459102wrm.98.2022.11.18.05.28.40 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 18 Nov 2022 05:28:40 -0800 (PST) Received: from zen (localhost [127.0.0.1]) by zen.linaroharston (Postfix) with ESMTP id 11C631FFB7; Fri, 18 Nov 2022 13:28:40 +0000 (GMT) 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> User-agent: mu4e 1.9.2; emacs 28.2.50 From: Alex =?utf-8?Q?Benn=C3=A9e?= To: Chao Peng Cc: 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 , Sean Christopherson , 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 Date: Fri, 18 Nov 2022 13:23:51 +0000 In-reply-to: <20221118013201.GA456562@chaop.bj.intel.com> Message-ID: <87o7t475o7.fsf@linaro.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1668778123; a=rsa-sha256; cv=none; b=qYPue96IBheMkqJ4RbRXzcZb9UEbD0GJTJ2aGF3CmR7mLx+zoGB0CUHqG2qdzXg7qvwPjn M9acWFMGz3AFkMn9/F3qtDLftNYLJczo7IeVyzHwdXp+ooDXgBP3Nd8mN5GjAAbaPyXKZm zug9xIYyD3Uq/4HtyO7Qn3aKcs082no= ARC-Authentication-Results: i=1; imf30.hostedemail.com; dkim=pass header.d=linaro.org header.s=google header.b="X/gqqsl/"; dmarc=pass (policy=none) header.from=linaro.org; spf=pass (imf30.hostedemail.com: domain of alex.bennee@linaro.org designates 209.85.221.47 as permitted sender) smtp.mailfrom=alex.bennee@linaro.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1668778123; 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=jFuAN0qalS8PXGclZBpJGpqKwSse98B1zaIXuj/qhsM=; b=2WSqMbCVgyfbbLFVF+Azytpg8OWgk0P3xDJZ1FhR9QLfO1M+lcaKK2dEUJK5gqrCGRnul2 R3Jwz11HcXkmPwhl9aTojLNxMD7zOStANyj/UWT097H4oqaoCIw6VHTNACoNVE8a/0zDkV loqHAZbdBaytUTU8V/dDF0kXzRUbep0= Authentication-Results: imf30.hostedemail.com; dkim=pass header.d=linaro.org header.s=google header.b="X/gqqsl/"; dmarc=pass (policy=none) header.from=linaro.org; spf=pass (imf30.hostedemail.com: domain of alex.bennee@linaro.org designates 209.85.221.47 as permitted sender) smtp.mailfrom=alex.bennee@linaro.org X-Rspam-User: X-Stat-Signature: ykg7yfi1ebcioyjq4wdqcaz9g3f46w3q X-Rspamd-Queue-Id: E182C80008 X-Rspamd-Server: rspam11 X-HE-Tag: 1668778122-558638 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: Chao Peng writes: > On Thu, Nov 17, 2022 at 03:08:17PM +0000, Alex Benn=C3=A9e wrote: >>=20 >> >> >> > + >> >> >> > + /* KVM_EXIT_MEMORY_FAULT */ >> >> >> > + struct { >> >> >> > + #define KVM_MEMORY_EXIT_FLAG_PRIVATE (1 << 0) >> >> >> > + __u32 flags; >> >> >> > + __u32 padding; >> >> >> > + __u64 gpa; >> >> >> > + __u64 size; >> >> >> > + } memory; >> >> >> > + >> >> >> > +If exit reason is KVM_EXIT_MEMORY_FAULT then it indicates that = the VCPU has >> >> >> > +encountered a memory error which is not handled by KVM kernel m= odule and >> >> >> > +userspace may choose to handle it. The 'flags' field indicates = the memory >> >> >> > +properties of the exit. >> >> >> > + >> >> >> > + - KVM_MEMORY_EXIT_FLAG_PRIVATE - indicates the memory error is= caused by >> >> >> > + private memory access when the bit is set. Otherwise the mem= ory error is >> >> >> > + caused by shared memory access when the bit is clear. >> >> >>=20 >> >> >> What does a shared memory access failure entail? >> >> > >> >> > In the context of confidential computing usages, guest can issue a >> >> > shared memory access while the memory is actually private from the = host >> >> > point of view. This exit with bit 0 cleared gives userspace a chanc= e to >> >> > convert the private memory to shared memory on host. >> >>=20 >> >> 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: >> >>=20 >> >> 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. >>=20 >> OK so how about: >>=20 >> 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. --=20 Alex Benn=C3=A9e