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 29232C77B7C for ; Thu, 20 Apr 2023 22:16:06 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 702BE900004; Thu, 20 Apr 2023 18:16:05 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 6B1C1900002; Thu, 20 Apr 2023 18:16:05 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 57994900004; Thu, 20 Apr 2023 18:16:05 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) by kanga.kvack.org (Postfix) with ESMTP id 44DD9900002 for ; Thu, 20 Apr 2023 18:16:05 -0400 (EDT) Received: from smtpin17.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id DD20CAC017 for ; Thu, 20 Apr 2023 22:16:04 +0000 (UTC) X-FDA: 80703178248.17.02D93AF Received: from mga01.intel.com (mga01.intel.com [192.55.52.88]) by imf14.hostedemail.com (Postfix) with ESMTP id A580510001D for ; Thu, 20 Apr 2023 22:16:01 +0000 (UTC) Authentication-Results: imf14.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b="c/UD9I2T"; spf=pass (imf14.hostedemail.com: domain of dave.hansen@intel.com designates 192.55.52.88 as permitted sender) smtp.mailfrom=dave.hansen@intel.com; dmarc=pass (policy=none) header.from=intel.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1682028963; 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=KMngbKO2te67l34ExbKzqrp6nIsuH7lP6/1PlsjRDCk=; b=woSzSC6/Z8tzBVTh/zawPkBHY27xzfwWjyHh7HmQAKiZR0/E6B2335GIYdC0IAbg1od21n Y5l1gFnni4owXLRd6t0ufPzSwVgdPAD+zmpKD83xEObHGIgNqzmbR9GeU7SjwptBm5bvP5 DABFCOClfEICaOLsbfkzrD0We6CVqxg= ARC-Authentication-Results: i=1; imf14.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b="c/UD9I2T"; spf=pass (imf14.hostedemail.com: domain of dave.hansen@intel.com designates 192.55.52.88 as permitted sender) smtp.mailfrom=dave.hansen@intel.com; dmarc=pass (policy=none) header.from=intel.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1682028963; a=rsa-sha256; cv=none; b=W+PaoxqSGRzZMNe1pfSe6L/04QH9o6WHDy9y7QWkvr6ngf1r7bpEQBKAvHaAyWZNvNpKA2 eAllKOH/gWhDNdIdfLfaMBZK/OWE2GUljC9bK4Z/rF/p04FW23TK5zFUlt9x5tkDYHnqte rS3vf9iK5F3ovUbfQs02JfLS3WIzMAk= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1682028962; x=1713564962; h=message-id:date:mime-version:subject:to:cc:references: from:in-reply-to:content-transfer-encoding; bh=IS7ZXuBIDcdEHWCz73K8Pgp/gskIbDBObXQBP3E1Hs8=; b=c/UD9I2T1bN3P9hHZ7Wy/x+FHcmiTX1z4UI3WBW2KAx/YM6XKPW8x0p7 KyyrLg+mOjPMoXTyf6JrL2oM4/GpFK7SB2phxIrdjy3XhkqCHGqBHw9nj vYNqgbJf0YQ+4TyR63J8brrLZAZOwau2LuG6em1IFoabVwl619GugdgLM hIqmPdNkTpXygtHudMe6T5qbu8l0lYaVykRUOVj0LEIYkivBeXyQgEd2t //TZ3ZVJO+vpFepy0sVjYfLDtsOZc03qlvygP2MEhJ0IgdEmtCR3KJfgw GyG6EZj8rjEoV0Qn2EP1phYJ5kVxHD3OAkdiiRsBS8rQmXfkk0/0vMjhN g==; X-IronPort-AV: E=McAfee;i="6600,9927,10686"; a="373781279" X-IronPort-AV: E=Sophos;i="5.99,213,1677571200"; d="scan'208";a="373781279" Received: from fmsmga008.fm.intel.com ([10.253.24.58]) by fmsmga101.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 20 Apr 2023 15:16:00 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6600,9927,10686"; a="756693577" X-IronPort-AV: E=Sophos;i="5.99,213,1677571200"; d="scan'208";a="756693577" Received: from ashleyst-mobl1.amr.corp.intel.com (HELO [10.209.71.65]) ([10.209.71.65]) by fmsmga008-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 20 Apr 2023 15:15:58 -0700 Message-ID: <69ba1760-a079-fd8f-b079-fcb01e3eedec@intel.com> Date: Thu, 20 Apr 2023 15:15:58 -0700 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.10.0 Subject: Re: [RFC 45/48] RISC-V: ioremap: Implement for arch specific ioremap hooks Content-Language: en-US To: Atish Patra , linux-kernel@vger.kernel.org Cc: Rajnesh Kanwal , Alexandre Ghiti , Andrew Jones , Andrew Morton , Anup Patel , Atish Patra , =?UTF-8?B?QmrDtnJuIFTDtnBlbA==?= , Suzuki K Poulose , Will Deacon , Marc Zyngier , Sean Christopherson , linux-coco@lists.linux.dev, Dylan Reid , abrestic@rivosinc.com, Samuel Ortiz , Christoph Hellwig , Conor Dooley , Greg Kroah-Hartman , Guo Ren , Heiko Stuebner , Jiri Slaby , kvm-riscv@lists.infradead.org, kvm@vger.kernel.org, linux-mm@kvack.org, linux-riscv@lists.infradead.org, Mayuresh Chitale , Palmer Dabbelt , Paolo Bonzini , Paul Walmsley , Uladzislau Rezki References: <20230419221716.3603068-1-atishp@rivosinc.com> <20230419221716.3603068-46-atishp@rivosinc.com> From: Dave Hansen In-Reply-To: <20230419221716.3603068-46-atishp@rivosinc.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Rspamd-Server: rspam05 X-Rspamd-Queue-Id: A580510001D X-Stat-Signature: 3ixseuwwgybq3ttidoocsncp6meiq55e X-Rspam-User: X-HE-Tag: 1682028961-432958 X-HE-Meta: U2FsdGVkX183G6f6UFYmxQ/QKNCgfBZ6tKLVbSHgBj5x7utA8QHmFJ4F3r8jIWKiSdp09in1Ae3/n8q8h9D2EP85Mm0bBJP0CNi1Tv54vCPGjqXRyzgidZocrhLWuGIwqt3QXWkIvTOf8r9GPMDsyF5V3z7irtRvBL/AYJWzBMCAQFaG2bb7urOPMZ7KH+/Y8e6fWu66yzc7KgQL6GP1VgWEhrh/SBcRjatry3nhRiqq+HhqweQYsJ4vpoZCzMCo6/SeFiTuJOCEBNMfLxRAVdQCK8yVzOWny1/R/ckil28K/D7XXXK5Cr4nMYDx5Bd+yHQQPPiei+OWWk/GeUZSEeq8h/Wxjcl3vccF91Se1xUC2Pcrcx7Z6OWOr031QGBCDCKf8VmSOE5DQmM9RwiYlYsHuzt550GBDMpbM0mzZh4+TreFXE4D+wbtsSq5xIp3hoIXVgOXXS++c3MWereJ6SQdL5xANVL4nc3Tdy1nuPeRiTkT89T1Q0OZtVC+fkUrjDkmmyyC+R1bNQsP7DJohHoRxiEsY2mara4AbG9UxH6tdJ4n6hTqMa3Rl8nR/kA7JT4oi8fVqtJLvxdPT6OlBN1d6tSiMZTYB8zrELNqWxcYSbjNNmg1pVkI29gPYvL6RPd8/LLeL5YdiqVAxOa36vkyiNR54ffxAzK34BcHdc4SIRp0ZWAKMkhavmnqwFTNYmFpdiNhxEFKsehxpcjCH6vxc+XoPn9MQZUFX/aKcFC6GN7ZyT/ZaBP9cEtPsB/rpRGCDT08F0sVG7hP0me4Rpubh6fKxvU4KmZn479AjmeqRk7P22LjWG2d9Dik4/yxfiIVEL5ZruNDAoEbpJjMCsKhEBbVWXYSq+uN52/ILT6PKixXMorHLkN9RrPgTA8oohDhqcg7zfK8fsGiNj2JSlrsifncuNfBK+zGIKuKQKWP/ezj6Ie+PAAk78EfOhIUcIzBuLrkYrnm+UNhS1x MWTi1zws V7xv/6MgCY/sfPewi81tYonJTrV/uv2Th6RBLHese6MV1nMLj3s2Haxq3eLIt7+bVR3E85IXvzzgGKn0sYsjpkQ3nMnLqD6VBvriQbQLWqLyM027qA5Kq5tTLXQjNfbaD01FMiY/1jIKpcP0= 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 4/19/23 15:17, Atish Patra wrote: > The guests running in CoVE must notify the host about its mmio regions > so that host can enable mmio emulation. This one doesn't make a lot of sense to me. The guest and host must agree about the guest's physical layout up front. In general, the host gets to dictate that layout. It tells the guest, up front, what is present in the guest physical address space. This callback appears to say to the host: Hey, I (the guest) am treating this guest physical area as MMIO. But the host and guest have to agree _somewhere_ what the MMIO is used for, not just that it is being used as MMIO.