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 A5D37C28B30 for ; Thu, 20 Mar 2025 07:25:08 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id DBDA8280002; Thu, 20 Mar 2025 03:25:06 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id D6C73280001; Thu, 20 Mar 2025 03:25:06 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id C3518280002; Thu, 20 Mar 2025 03:25:06 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0016.hostedemail.com [216.40.44.16]) by kanga.kvack.org (Postfix) with ESMTP id A4DD1280001 for ; Thu, 20 Mar 2025 03:25:06 -0400 (EDT) Received: from smtpin16.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id 5CD98C0E68 for ; Thu, 20 Mar 2025 07:25:07 +0000 (UTC) X-FDA: 83241093054.16.0E4B644 Received: from mail.loongson.cn (mail.loongson.cn [114.242.206.163]) by imf17.hostedemail.com (Postfix) with ESMTP id 9C4DD4000C for ; Thu, 20 Mar 2025 07:25:03 +0000 (UTC) Authentication-Results: imf17.hostedemail.com; dkim=none; dmarc=none; spf=pass (imf17.hostedemail.com: domain of maobibo@loongson.cn designates 114.242.206.163 as permitted sender) smtp.mailfrom=maobibo@loongson.cn ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1742455504; 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=okNzXWR/GpeRoMOyYq4lDHm4W4rmEwf8it/IeOrl6TU=; b=YKhbYJBpHLdnrKFYVRnBEKsSMvgY3xPVnjciw9AzNzUZZPpd2VWEnL/QBOZT0QdrcBdbRT ntvVfrgsMxJ0C4pWA5aUSh1El0+1WWY2y1VnIVM0HROspQ1q5zFG5L1jJskZr5mJ9AhxQO CMDYUP/I4GByh7AMHYq3aHa/T+TiF1s= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1742455504; a=rsa-sha256; cv=none; b=teCTluoKhba83EINmUxc7+j9USTs/5juGI8aySw9TdP5kQ50eFqOWZdjgkxwMOn2Z1/6Mb zy/XhNXnIpPioZYYFNsYIMhFtB2of6NIqaN8VbjFQRurmISsi8pe+Nn4dU2sCbsen3depq 6fHPc+SJz2lvjaFCfT9JhYIObRur/E0= ARC-Authentication-Results: i=1; imf17.hostedemail.com; dkim=none; dmarc=none; spf=pass (imf17.hostedemail.com: domain of maobibo@loongson.cn designates 114.242.206.163 as permitted sender) smtp.mailfrom=maobibo@loongson.cn Received: from loongson.cn (unknown [10.20.42.62]) by gateway (Coremail) with SMTP id _____8DxbKzLwttnGyeeAA--.5355S3; Thu, 20 Mar 2025 15:24:59 +0800 (CST) Received: from [10.20.42.62] (unknown [10.20.42.62]) by front1 (Coremail) with SMTP id qMiowMAxj8XEwttnjEdVAA--.52753S3; Thu, 20 Mar 2025 15:24:55 +0800 (CST) Subject: Re: [PATCH v3 1/1] KVM: arm64: Allow cacheable stage 2 mapping using VMA flags From: bibo mao 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> Message-ID: Date: Thu, 20 Mar 2025 15:24:12 +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:qMiowMAxj8XEwttnjEdVAA--.52753S3 X-CM-SenderInfo: xpdruxter6z05rqj20fqof0/ X-Coremail-Antispam: 1Uk129KBj93XoWxGr1xZw1rArW5ury3ZF48KrX_yoW5Gr4Upr 97t3WDKan7Xr4Syr4vgw42gF40yw4rKr4UXw1YgryUuwn093ZrtFWrta12kF9rJr1rX39F qF45t347XFyavFcCm3ZEXasCq-sJn29KB7ZKAUJUUUU7529EdanIXcx71UUUUU7KY7ZEXa sCq-sGcSsGvfJ3Ic02F40EFcxC0VAKzVAqx4xG6I80ebIjqfuFe4nvWSU5nxnvy29KBjDU 0xBIdaVrnRJUUUPFb4IE77IF4wAFF20E14v26r1j6r4UM7CY07I20VC2zVCF04k26cxKx2 IYs7xG6rWj6s0DM7CIcVAFz4kK6r1Y6r17M28lY4IEw2IIxxk0rwA2F7IY1VAKz4vEj48v e4kI8wA2z4x0Y4vE2Ix0cI8IcVAFwI0_Xr0_Ar1l84ACjcxK6xIIjxv20xvEc7CjxVAFwI 0_Gr0_Cr1l84ACjcxK6I8E87Iv67AKxVW0oVCq3wA2z4x0Y4vEx4A2jsIEc7CjxVAFwI0_ GcCE3s1ln4kS14v26r1Y6r17M2AIxVAIcxkEcVAq07x20xvEncxIr21l57IF6xkI12xvs2 x26I8E6xACxx1l5I8CrVACY4xI64kE6c02F40Ex7xfMcIj6xIIjxv20xvE14v26r126r1D McIj6I8E87Iv67AKxVW8JVWxJwAm72CE4IkC6x0Yz7v_Jr0_Gr1lF7xvr2IY64vIr41lc7 I2V7IY0VAS07AlzVAYIcxG8wCY1x0262kKe7AKxVWUtVW8ZwCF04k20xvY0x0EwIxGrwCF x2IqxVCFs4IE7xkEbVWUJVW8JwCFI7km07C267AKxVWUXVWUAwC20s026c02F40E14v26r 1j6r18MI8I3I0E7480Y4vE14v26r106r1rMI8E67AF67kF1VAFwI0_Wrv_Gr1UMIIYrxkI 7VAKI48JMIIF0xvE2Ix0cI8IcVAFwI0_Jr0_JF4lIxAIcVC0I7IYx2IY6xkF7I0E14v26r 4j6F4UMIIF0xvE42xK8VAvwI8IcIk0rVWUJVWUCwCI42IY6I8E87Iv67AKxVW8JVWxJwCI 42IY6I8E87Iv6xkF7I0E14v26r4j6r4UJbIYCTnIWIevJa73UjIFyTuYvjxU4qg4DUUUU X-Rspam-User: X-Rspamd-Server: rspam11 X-Rspamd-Queue-Id: 9C4DD4000C X-Stat-Signature: taegncsat5an5pg1i59due1z7d8cgrqn X-HE-Tag: 1742455503-818802 X-HE-Meta: U2FsdGVkX18PmrDUY0ZFV8GY+Ai4kJdXUm9G+31DG/Dk9VJyIgTT4wkz05BMi02kET4mWW9Da8PcQ9Qh/Hu+F+bPZWJGvP8ttusLydCLbYX+aXFFnSY0iBx9VyZ6SfBGv19Bidiv+5pRsHv/k9/d6x6PS263G+YmV0haS3BcTbJTUfYttyDZdPhez4lYK+pf0De5RREcu+EkKRaiGotOhfU3wU8dv8iWmipbSk5X7oRm7/kR33bZl186kN5h2NDLxjdaygR8nyFdknunb+a+adS1jw9h8HoJhg7U85YO7gdok1ocwVo/trkRfM0NmK9W0WhkBTcToaPWEQmy9gs0hF5TYUHHdmwBPWJJ1xUW7YAzV7M7hB+pcarQpxMkz61GogHM0o9gkpzuk7zcCukF/EIs4bEPPqc92laq0uihccgFrMCgmNzfFlvdx4kWc4tUSr1UKNcWHMnUxOiKMWphGW77Wl+rsZRB6ETDtDEDbiiKcCvMon+B30ZgImIl/3dS+dN54ODmHamr3/EKMC28bootWIcOAyUvJiyVl6lNWrJ8fI2Oa7AM2jlZuJqfC+MLN/SgT7e1RCkoumKXOPCD6kPwqL7GHlvUicexYG2o2oj1kcuHgepttlaEiCVWN0SEFg6ZHpdAVGsYzwmEz/wyG2pKIUUqNGiuhjv29h0+Dm7BOpwp1KNnuY2TN5wRBjLy+eZr/ili1Y04U8wA+wBArHq+wdmyc0TqJrsSEwX2ECF1Nt5eo8zmAXACok7zTefDWe7AcWuJYc2DGUsO62CqWLxGRtyKMRBE6bWzZX5klN/L0fyvG6DxTYdKpY9/asaeFC1TvUxkpYW91OsJD7GY7VPdKlki+ghox2TLkiD9z5OQQ5wMdsMHz3Ntb22jYa8JlzCh9ix+elC1qAKZUWlyaZUr/a5rofJIRxb/4CkNg4zRM6H8ZxUU5oufZxVLzehCfKd3ba4uMNRR+GBx/RQ x+Msn7+s PsBv4CHeuAmwXs+6UvHLCNceXXiqGLvV0qOxSBhaaieBebj0jm+9ImzBShseM6MYLVR1ElSVEas8IMwVU1FlBLtNJYUgcLbv0RSOiYSOtQ/dJf7VaFDS8cDEIWQ== 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/20 上午11:30, bibo mao wrote: > > > 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. Sorry, I do not state this clearly. My meaning is tor add cachable attribute in memslot. It is acquired from prot of VMA at memslot creation, and checked at S2 page fault fastpath. So it is unnecessary to find vma at S2 page fault fastpath, only memslot is enough. And cache attribute write-combined should be added also since some GPU memory can be mapped with WC attribute in vfio-gpu driver. Regards Bibo Mao > > Regards > Bibo Mao >> >> VM_MTE_ALLOWED is an example of this. >> >> Thanks, >> Oliver >> >