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 B76C4C28B30 for ; Thu, 20 Mar 2025 03:31:36 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 46F0B280002; Wed, 19 Mar 2025 23:31:35 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 446EC280001; Wed, 19 Mar 2025 23:31:35 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 33566280002; Wed, 19 Mar 2025 23:31:35 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0014.hostedemail.com [216.40.44.14]) by kanga.kvack.org (Postfix) with ESMTP id 155C7280001 for ; Wed, 19 Mar 2025 23:31:35 -0400 (EDT) Received: from smtpin09.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id 4021080A58 for ; Thu, 20 Mar 2025 03:31:35 +0000 (UTC) X-FDA: 83240504550.09.6ECE56B Received: from mail.loongson.cn (mail.loongson.cn [114.242.206.163]) by imf09.hostedemail.com (Postfix) with ESMTP id 91286140003 for ; Thu, 20 Mar 2025 03:31:32 +0000 (UTC) Authentication-Results: imf09.hostedemail.com; dkim=none; spf=pass (imf09.hostedemail.com: domain of maobibo@loongson.cn designates 114.242.206.163 as permitted sender) smtp.mailfrom=maobibo@loongson.cn; dmarc=none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1742441493; 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; bh=0v1mfDfXZYY+ngcMqvJwjlv+wrqk76RhbROMRHxGJtM=; b=PRFImweU9qcL5LyIi0dXuBK1LTk5XZDstSgwqHMQt6KmB8hJ8+MFBew6L9v2Gbmbj+TBVz AkEyLwA5KsrSIGHDYglvnMS4xLnkcd4P1+y9jbGYHq/Fr6eJYw1WjjEx6Gjv+GfDp58FvY BYgIKT31/ilQjl1dxS0ktZF7E2QNZrA= ARC-Authentication-Results: i=1; imf09.hostedemail.com; dkim=none; spf=pass (imf09.hostedemail.com: domain of maobibo@loongson.cn designates 114.242.206.163 as permitted sender) smtp.mailfrom=maobibo@loongson.cn; dmarc=none ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1742441493; a=rsa-sha256; cv=none; b=dQg3XZQb5s5LpsLaHTZXjrzOgfAS1wafy4EcAwpT8E/SRz0LiBLZ3r0owuRbCOqpTRgMGj /wU46yUmWSKcr1UMHv0nZRITP31dYz0hDR7dhrKQs8k9EgsUTKqaxMTy6CztH6NZfaiEf5 KZcCjPhPqgnbu0qpWGWygOdHZe4ksJ8= Received: from loongson.cn (unknown [10.20.42.62]) by gateway (Coremail) with SMTP id _____8CxqmoQjNtnSfGdAA--.5434S3; Thu, 20 Mar 2025 11:31:28 +0800 (CST) Received: from [10.20.42.62] (unknown [10.20.42.62]) by front1 (Coremail) with SMTP id qMiowMDx_MQKjNtnM_hUAA--.47363S3; Thu, 20 Mar 2025 11:31:26 +0800 (CST) Subject: Re: [PATCH v3 1/1] KVM: arm64: Allow cacheable stage 2 mapping using VMA flags To: Oliver Upton , David Hildenbrand Cc: Catalin Marinas , Jason Gunthorpe , Marc Zyngier , Ankit Agrawal , "joey.gouly@arm.com" , "suzuki.poulose@arm.com" , "yuzenghui@huawei.com" , "will@kernel.org" , "ryan.roberts@arm.com" , "shahuang@redhat.com" , "lpieralisi@kernel.org" , Aniket Agashe , Neo Jia , Kirti Wankhede , "Tarun Gupta (SW-GPU)" , Vikram Sethi , Andy Currid , Alistair Popple , John Hubbard , Dan Williams , Zhi Wang , Matt Ochs , Uday Dhoke , Dheeraj Nigam , Krishnakant Jaju , "alex.williamson@redhat.com" , "sebastianene@google.com" , "coltonlewis@google.com" , "kevin.tian@intel.com" , "yi.l.liu@intel.com" , "ardb@kernel.org" , "akpm@linux-foundation.org" , "gshan@redhat.com" , "linux-mm@kvack.org" , "ddutile@redhat.com" , "tabba@google.com" , "qperret@google.com" , "seanjc@google.com" , "kvmarm@lists.linux.dev" , "linux-kernel@vger.kernel.org" , "linux-arm-kernel@lists.infradead.org" References: <86r033olwv.wl-maz@kernel.org> <87tt7y7j6r.wl-maz@kernel.org> <8634fcnh0n.wl-maz@kernel.org> <86wmcmn0dp.wl-maz@kernel.org> <20250318125527.GP9311@nvidia.com> From: bibo mao Message-ID: Date: Thu, 20 Mar 2025 11:30:43 +0800 User-Agent: Mozilla/5.0 (X11; Linux loongarch64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-CM-TRANSID:qMiowMDx_MQKjNtnM_hUAA--.47363S3 X-CM-SenderInfo: xpdruxter6z05rqj20fqof0/ X-Coremail-Antispam: 1Uk129KBj93XoW7WFW5WFW5Kr47Ww15ZF4fJFc_yoW8ZF1Dpr yxt3ZFka1kXrySyws29w42gF40yw4Fqr4UXw15Kr1UCwn09FnrKFWFya12kFsrAF1Sq39F vFZ0q347JFya9abCm3ZEXasCq-sJn29KB7ZKAUJUUUU7529EdanIXcx71UUUUU7KY7ZEXa sCq-sGcSsGvfJ3Ic02F40EFcxC0VAKzVAqx4xG6I80ebIjqfuFe4nvWSU5nxnvy29KBjDU 0xBIdaVrnRJUUUPFb4IE77IF4wAFF20E14v26r1j6r4UM7CY07I20VC2zVCF04k26cxKx2 IYs7xG6rWj6s0DM7CIcVAFz4kK6r1Y6r17M28lY4IEw2IIxxk0rwA2F7IY1VAKz4vEj48v e4kI8wA2z4x0Y4vE2Ix0cI8IcVAFwI0_Xr0_Ar1l84ACjcxK6xIIjxv20xvEc7CjxVAFwI 0_Gr0_Cr1l84ACjcxK6I8E87Iv67AKxVW0oVCq3wA2z4x0Y4vEx4A2jsIEc7CjxVAFwI0_ GcCE3s1ln4kS14v26r1Y6r17M2AIxVAIcxkEcVAq07x20xvEncxIr21l57IF6xkI12xvs2 x26I8E6xACxx1l5I8CrVACY4xI64kE6c02F40Ex7xfMcIj6xIIjxv20xvE14v26r126r1D McIj6I8E87Iv67AKxVWUJVW8JwAm72CE4IkC6x0Yz7v_Jr0_Gr1lF7xvr2IY64vIr41lc7 I2V7IY0VAS07AlzVAYIcxG8wCY1x0262kKe7AKxVWUtVW8ZwCF04k20xvY0x0EwIxGrwCF x2IqxVCFs4IE7xkEbVWUJVW8JwCFI7km07C267AKxVWUXVWUAwC20s026c02F40E14v26r 1j6r18MI8I3I0E7480Y4vE14v26r106r1rMI8E67AF67kF1VAFwI0_Wrv_Gr1UMIIYrxkI 7VAKI48JMIIF0xvE2Ix0cI8IcVAFwI0_Jr0_JF4lIxAIcVC0I7IYx2IY6xkF7I0E14v26r 4j6F4UMIIF0xvE42xK8VAvwI8IcIk0rVWUJVWUCwCI42IY6I8E87Iv67AKxVWUJVW8JwCI 42IY6I8E87Iv6xkF7I0E14v26r4j6r4UJbIYCTnIWIevJa73UjIFyTuYvjxUceOJUUUUU X-Stat-Signature: eazyi177pw5dris8766xu7mxu6r7do4b X-Rspamd-Queue-Id: 91286140003 X-Rspam-User: X-Rspamd-Server: rspam09 X-HE-Tag: 1742441492-564499 X-HE-Meta: U2FsdGVkX18bK+dj/TgFLJW7N/5tNNJvroVjDiFHZ3HXbSdKPQ5YmJiLLfOircQhCfqIW35i5JJMZeXZe5dHW7AC64W6aDKYAZ7RBCRzCK30+XJJypxp8Y7w4KPGOWSgN/ADsXsDnQTuGbpqkRF+3Pd8tJtBdW1KBI6jd0216i2p6I5DUhnQb1qvRdxLsbmbYfUd4KYdLtfn2nvGBjzBoiGCk7dfomRhtADWYAT9eFIv9AJ24Fs7RzFkIcswPiHohZGPsmQ5+O86cqXBGB1cvsalr0iTYTD8WBESOtthaiWOmdJWIGtfMP/1YtJFcCKFvlkwB2Ce4tiiLoTHWgqvyztQi8mxklsPpTFbbuYlx1p+7g9KwDVgBHlNTm9rLxek/TFPSMITuENzBHL4q6viAk0BFHMSZ7znL3i/zOLBcTlkt7kd5V2jP2oetpfMYk9Z9UoMnY8Bb8SVW9LNJmwDtZOJbBBHfw5inM42FGy+22I6Ce0QveKYprG2uuT1SVxNlVHB2AWinLqT4/fLrIrxTdM9PH73wiZcn60brsWvwu6z8J62zBLCebd3TZ06Rwla9OQSvq2Rvm7ROm/Wbou9eiNu2AQRj54duG16odl7wCo1e2BLJtROYgyWfylF8Xg2orsA3VvZg6qHy9VyFFQZFRN54y44cQdDtk3x9Ske70Ntpzei2f8E7+zzoiOPgP2MAD6+/3H3T14x4KtIubRDq2pg9XXJNc9qifgFX3tvhqGhotElxvAgK2cUcgfuySg+0PJeOxBMH4l7p9dGnCQQkc9PvTZlEWXqH1UYbZ49U78eJxPsdIRvTBMIlmxIcCwSy0pmcDq5fZUsR3JW2pkuvKyVABkk/RCV9n9aCak8A/dbqcV5ItClXAhNvcT8+HY905W5KzVE00Ps0BRm3irKIVJbi+kbj3t7cEvjzuyiCtuySfrHIKXmMRWMwa2u0ynPPFCDLmMDS3xuEdt5Pfz udlfuQSy UXL3nZXb9WXKzDMe28RlULygZfuJ80G2EVej/+zxGwlvAp7gws8BEEARkU/UBLryCRXAWs3SXEaSYp314lZMpTsYZCKQS8gwU1poweRWyKFm/0BHFTrl+QlDgzw== 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: List-Subscribe: List-Unsubscribe: On 2025/3/19 上午3:40, Oliver Upton wrote: > On Tue, Mar 18, 2025 at 08:35:38PM +0100, David Hildenbrand wrote: >> On 18.03.25 20:27, Catalin Marinas wrote: >>> On Tue, Mar 18, 2025 at 09:55:27AM -0300, Jason Gunthorpe wrote: >>>> On Tue, Mar 18, 2025 at 09:39:30AM +0000, Marc Zyngier wrote: >>>>> The memslot must also be created with a new flag ((2c) in the taxonomy >>>>> above) that carries the "Please map VM_PFNMAP VMAs as cacheable". This >>>>> flag is only allowed if (1) is valid. >>>>> >>>>> This results in the following behaviours: >>>>> >>>>> - If the VMM creates the memslot with the cacheable attribute without >>>>> (1) being advertised, we fail. >>>>> >>>>> - If the VMM creates the memslot without the cacheable attribute, we >>>>> map as NC, as it is today. >>>> >>>> Is that OK though? >>>> >>>> Now we have the MM page tables mapping this memory as cachable but KVM >>>> and the guest is accessing it as non-cached. >>> >>> I don't think we should allow this. >>> >>>> I thought ARM tried hard to avoid creating such mismatches? This is >>>> why the pgprot flags were used to drive this, not an opt-in flag. To >>>> prevent userspace from forcing a mismatch. >>> >>> We have the vma->vm_page_prot when the memslot is added, so we could use >>> this instead of additional KVM flags. >> >> I thought we try to avoid messing with the VMA when adding memslots; because >> KVM_CAP_SYNC_MMU allows user space for changing the VMAs afterwards without >> changing the memslot? > > Any checks on the VMA at memslot creation is done out of courtesy to > userspace so it 'fails fast'. We repeat checks on the VMA at the time of > fault to handle userspace twiddling VMAs behind our back. yes, I think it is better to add cachable attribute in memslot, it can be checked on the VMA at memslot creation. Also cache attribute can be abstracted with cachable/uc/wc type rather than detailed arch specified. Regards Bibo Mao > > VM_MTE_ALLOWED is an example of this. > > Thanks, > Oliver >