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 X-Spam-Level: X-Spam-Status: No, score=-9.6 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, NICE_REPLY_A,SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id D0D1CC433F5 for ; Fri, 10 Sep 2021 15:05:53 +0000 (UTC) Received: from lists.xenproject.org (lists.xenproject.org [192.237.175.120]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 93C3860F5D for ; Fri, 10 Sep 2021 15:05:53 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 93C3860F5D Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=xen.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=lists.xenproject.org Received: from list by lists.xenproject.org with outflank-mailman.184536.333211 (Exim 4.92) (envelope-from ) id 1mOi65-00034W-Sd; Fri, 10 Sep 2021 15:05:45 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 184536.333211; Fri, 10 Sep 2021 15:05:45 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1mOi65-00034P-NP; Fri, 10 Sep 2021 15:05:45 +0000 Received: by outflank-mailman (input) for mailman id 184536; Fri, 10 Sep 2021 15:05:44 +0000 Received: from mail.xenproject.org ([104.130.215.37]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1mOi64-00034D-Qn for xen-devel@lists.xenproject.org; Fri, 10 Sep 2021 15:05:44 +0000 Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1mOi62-00011w-Vb; Fri, 10 Sep 2021 15:05:42 +0000 Received: from [54.239.6.184] (helo=a483e7b01a66.ant.amazon.com) by xenbits.xenproject.org with esmtpsa (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1mOi62-0006Z7-PY; Fri, 10 Sep 2021 15:05:42 +0000 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org; s=20200302mail; h=Content-Transfer-Encoding:Content-Type:In-Reply-To: MIME-Version:Date:Message-ID:From:References:Cc:To:Subject; bh=gFJ+sQJ/dsLn0g1GcAS4YzhE7toEGNPQlDe3fadGH8c=; b=CWQgc/Jv6rpwjuXVC+1PZOHGRN DChmFfv1p+NCNHTs5zOgvKOvJshSbFdI4ZmOPlOZOB1/yyLxPSWSi8jQk3lsZdxVNtZ0v7U7apu2t GfQ5HeiK0x5MSuw8wRKpGpDR7KUkQxsELCgNZ0HoIz2hcjc3/Plax8tFvFbMlcKClJUY=; Subject: Re: [PATCH 10/11] xen/arm: Do not map PCI ECAM space to Domain-0's p2m To: Oleksandr Andrushchenko , Oleksandr Andrushchenko , "xen-devel@lists.xenproject.org" Cc: "sstabellini@kernel.org" , Oleksandr Tyshchenko , Volodymyr Babchuk , Artem Mygaiev , "roger.pau@citrix.com" , Bertrand Marquis , Rahul Singh References: <20210903083347.131786-1-andr2000@gmail.com> <20210903083347.131786-11-andr2000@gmail.com> <35f7faf6-db90-f279-8ed1-fa4ba96812fb@xen.org> <468a868c-1183-e05f-0c92-3cba172cecb3@epam.com> <9ec2c22c-b834-1c87-71af-236e13538c4a@xen.org> <15a930ff-77d5-b962-b346-c586a2769009@epam.com> <733cd423-14f5-c028-8fdd-39aed34cd352@xen.org> <3c3c253c-4af7-ea25-5f73-a0f7319dab50@epam.com> <34abe11e-c2f9-50ce-fb79-836bfcfb11e0@xen.org> From: Julien Grall Message-ID: <9d563708-16c6-5400-7598-4502dfbb6c5d@xen.org> Date: Fri, 10 Sep 2021 16:05:40 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.14.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-GB Content-Transfer-Encoding: 8bit Hi Oleksandr, On 10/09/2021 16:01, Oleksandr Andrushchenko wrote: > > On 10.09.21 17:52, Julien Grall wrote: >> >> >> On 10/09/2021 15:38, Oleksandr Andrushchenko wrote: >>> [snip] >>> >>> >>>>>> What do you mean by "used by Domain-0 completely"? The hostbridge is owned by Xen so I don't think we can let dom0 access any MMIO regions by >>>>>> default. >>>>> >>>>> Now it's my time to ask why do you think Xen owns the bridge? >>>> >>>> Because nothing in this series indicates either way. So I assumed this should be owned by Xen because it will drive it. >>>> >>>>  From what you wrote below, it sounds like this is not the case. I think you want to have a design document sent along the series so we can easily know what's the expected design and validate that the code match the agreement. >>>> >>>> There was already a design document sent a few months ago. So you may want to refresh it (if needed) and send it again with this series. >>>> >>> Please see [1] which is the design document we use to implement PCI passthrough on Arm. >> >> Thank. Can you make sure to include at least in a link in your cover letter next time? > I will update the commit message to have more description on the design aspects >> >>> >>> For your convenience: >>> >>> " >>> >>> # Problem statement: >>> [snip] >>> >>> Only Dom0 and Xen will have access to the real PCI bus,​ guest will have a >>> direct access to the assigned device itself​. IOMEM memory will be mapped to >>> the guest ​and interrupt will be redirected to the guest. SMMU has to be >>> configured correctly to have DMA transaction." >>> >>> " >>> >>> # Discovering PCI Host Bridge in XEN: >>> >>> In order to support the PCI passthrough XEN should be aware of all the PCI host >>> bridges available on the system and should be able to access the PCI >>> configuration space. ECAM configuration access is supported as of now. XEN >>> during boot will read the PCI device tree node “reg” property and will map the >>> ECAM space to the XEN memory using the “ioremap_nocache ()” function. >>> >>> [snip] >>> >>> When Dom0 tries to access the PCI config space of the device, XEN will find the >>> corresponding host bridge based on segment number and access the corresponding >>> config space assigned to that bridge. >>> >>> Limitation: >>> * Only PCI ECAM configuration space access is supported. >>> * Device tree binding is supported as of now, ACPI is not supported. >>> * Need to port the PCI host bridge access code to XEN to access the >>> configuration space (generic one works but lots of platforms will required >>> some specific code or quirks). >>> >>> " >>> >>> Unfortunately the document had not been updated since then, but the question >>> >>> being discussed has not changed in the design: Domain-0 has full access to the bridge, >>> >>> Xen traps ECAM. (I am taking dom0less aside as that was not the target for the first phase) >> >> Having an update design document is quite important. This will allow reviewer to comment easily on overall approach and speed up the review as we can match to the agreed approach. >> >> So can this please be updated and sent along the work? >> >> In addition to that, it feels to me that the commit message should contain a summary of what you just pasted as this helps understanding the goal and approach of this patch. >> > If we are on the same page now will you be able to review the patch > > with respect to the design from RFC? I believe this was already done as I covered both side in my review. Cheers, -- Julien Grall