Received: by 2002:a05:6a10:17d3:0:0:0:0 with SMTP id hz19csp3510136pxb; Wed, 14 Apr 2021 07:09:48 -0700 (PDT) X-Google-Smtp-Source: ABdhPJydlMIRjtI9WlOKKGoe9PvhUbtYscCfaoGtkiyTlyVGJ11bNQ2SVYC7jTb+YyfKp33xsQrK X-Received: by 2002:a17:906:e4b:: with SMTP id q11mr7884212eji.540.1618409388747; Wed, 14 Apr 2021 07:09:48 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1618409388; cv=none; d=google.com; s=arc-20160816; b=iH17S2P8YI99Yyoqow88oGyTaAau7lTZTa2QeCfbK5/yChfiWJ5M/NJF7uC53XdFRp mbL+rV0PK0g6Nv+kElui16Uc9MGRgVaJso1zQcdSACElYmdSs+z5Wn+ZKxr+Wq7za77N za4UH1Y8tCK3613ERwmZ2451Y4Ctnl3Uy+xIZi12tJKvHmRrtiyKZbqzdoYAvEt6E8NH L8za9Wq/ZsZZhoxMaOfe9l2SctqLZOHsWHQBpK4exeN7Usi7DaACJM431/+mH3NMAWEU KENuLo7GcjroUxfiP+zRZZXqSUbzYCU3cUwm06h5uUt3R5vKMhcXV0TJ3vEbJEJE+dFs JxFQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:in-reply-to :mime-version:user-agent:date:message-id:from:cc:references:to :subject; bh=KyAyMhhnNoJSPuuuDz+UiYTB+9p2eFx4Jd4TLVAk5AE=; b=Pv0exdHjG7h+tL8WB68q0Xg0O6SBbh9vd/r/gIIpAV+raeo0FeE8t/ukvH0Vdkf9Hz /eUEz8oTp1KbaDZR65rohE8SMFqnnKjoPUTEM+jCDhl97H9kZvkt8CahaYSCB29vVNBR gAHc+vH+OdxLFS7omonyhVdgukPRVI8gA4D6nvSdkGZoYv0Z9DXYruJNfUpiGvtYpTC2 ik5fJ4SBFeURBov0jDTy+y8tXmP0lIO9tNarqlfBZRBHGQnyMsnrXyx4zgaKockBc3YY 1ZI0byFp3+eB05UmSOeGOEU6ngYtLV4So4OCGkH4fLZQxtbmK4U3YcJVpNurundWaxaE RlmA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=huawei.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id nc38si14837154ejc.362.2021.04.14.07.09.25; Wed, 14 Apr 2021 07:09:48 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=huawei.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1349565AbhDNG7b (ORCPT + 99 others); Wed, 14 Apr 2021 02:59:31 -0400 Received: from szxga07-in.huawei.com ([45.249.212.35]:17330 "EHLO szxga07-in.huawei.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1349592AbhDNG7O (ORCPT ); Wed, 14 Apr 2021 02:59:14 -0400 Received: from DGGEMS408-HUB.china.huawei.com (unknown [172.30.72.60]) by szxga07-in.huawei.com (SkyGuard) with ESMTP id 4FKtYZ4WhCz9xGM; Wed, 14 Apr 2021 14:56:34 +0800 (CST) Received: from [10.174.187.224] (10.174.187.224) by DGGEMS408-HUB.china.huawei.com (10.3.19.208) with Microsoft SMTP Server id 14.3.498.0; Wed, 14 Apr 2021 14:58:40 +0800 Subject: Re: [RFC PATCH v2 2/2] kvm/arm64: Try stage2 block mapping for host device MMIO To: Marc Zyngier References: <20210316134338.18052-1-zhukeqian1@huawei.com> <20210316134338.18052-3-zhukeqian1@huawei.com> <878s5up71v.wl-maz@kernel.org> <9f74392b-1086-a85e-72d8-f7bd99d65ea7@huawei.com> CC: , , , , Mark Rutland , James Morse , Suzuki K Poulose , Julien Thierry , From: Keqian Zhu Message-ID: Date: Wed, 14 Apr 2021 14:58:40 +0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 In-Reply-To: <9f74392b-1086-a85e-72d8-f7bd99d65ea7@huawei.com> Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: 7bit X-Originating-IP: [10.174.187.224] X-CFilter-Loop: Reflected Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Marc, On 2021/4/8 15:28, Keqian Zhu wrote: > Hi Marc, > > On 2021/4/7 21:18, Marc Zyngier wrote: >> On Tue, 16 Mar 2021 13:43:38 +0000, >> Keqian Zhu wrote: >>> [...] >>> >>> +/* >>> + * Find a mapping size that properly insides the intersection of vma and >>> + * memslot. And hva and pa have the same alignment to this mapping size. >>> + * It's rough because there are still other restrictions, which will be >>> + * checked by the following fault_supports_stage2_huge_mapping(). >> >> I don't think these restrictions make complete sense to me. If this is >> a PFNMAP VMA, we should use the biggest mapping size that covers the >> VMA, and not more than the VMA. > But as described by kvm_arch_prepare_memory_region(), the memslot may not fully > cover the VMA. If that's true and we just consider the boundary of the VMA, our > block mapping may beyond the boundary of memslot. Is this a problem? emm... Sorry I missed something. The fault_supports_stage2_huge_mapping() will check the boundary of memslot, so we don't need to check it here. I have send v3, please check that. BRs, Keqian