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 mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 46D65C433EF for ; Fri, 15 Oct 2021 07:28:25 +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 EB02C61108 for ; Fri, 15 Oct 2021 07:28:24 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org EB02C61108 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.209806.366363 (Exim 4.92) (envelope-from ) id 1mbHdY-0000nE-Tw; Fri, 15 Oct 2021 07:28:16 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 209806.366363; Fri, 15 Oct 2021 07:28:16 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1mbHdY-0000n7-Qm; Fri, 15 Oct 2021 07:28:16 +0000 Received: by outflank-mailman (input) for mailman id 209806; Fri, 15 Oct 2021 07:28:16 +0000 Received: from mail.xenproject.org ([104.130.215.37]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1mbHdY-0000mz-0R for xen-devel@lists.xenproject.org; Fri, 15 Oct 2021 07:28:16 +0000 Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1mbHdW-00064c-Io; Fri, 15 Oct 2021 07:28:14 +0000 Received: from [54.239.6.185] (helo=[192.168.0.140]) by xenbits.xenproject.org with esmtpsa (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1mbHdW-00044C-CE; Fri, 15 Oct 2021 07:28:14 +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:From: References:Cc:To:Subject:MIME-Version:Date:Message-ID; bh=aVbNQ2Xos+phCJl4b+tjmV/GubKei39SKO+4D10YkWM=; b=TBPR0hJTsMDrjQT4+Aqj4+Nu0x 5LiOXjXlJLhezYy3qqOOO2mgHkjzoJXzB1CYLT9niVcIME5KbXlpkqIQvceYMMvfl60kNEemuQm6c hg3jCVV5MWNeL97qcVdz0Tc8QXiO8H9+luaG//ARvvqjq21PpgHUsckj9P4HZAq3zJbo=; Message-ID: <6f82141c-8a0b-1e30-a996-223f7c0c508d@xen.org> Date: Fri, 15 Oct 2021 08:28:11 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:91.0) Gecko/20100101 Thunderbird/91.2.0 Subject: Re: [PATCH v6 3/3] arm/libxl: Emulated PCI device tree node in libxl [and 1 more messages] To: Ian Jackson , Bertrand Marquis Cc: xen-devel@lists.xenproject.org, Rahul Singh , Wei Liu , Anthony PERARD , Juergen Gross , Stefano Stabellini , Volodymyr Babchuk , Michal Orzel , Andre Przywara References: <7bdac405-a889-15e1-be19-5876f7253855@xen.org> <24926.53690.621007.507249@mariner.uk.xensource.com> <294BE20A-7E45-405C-BC19-C292295E85E3@arm.com> <24927.7235.736221.270358@mariner.uk.xensource.com> <8A04B9B2-E816-425E-BF1B-5A8B89F8836C@arm.com> <24936.28385.679884.535704@mariner.uk.xensource.com> From: Julien Grall In-Reply-To: <24936.28385.679884.535704@mariner.uk.xensource.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Hi Ian, On 14/10/2021 18:54, Ian Jackson wrote: > (Replying to both the earlier subthread on v5 and to the new v6 > patch.) > > Bertrand Marquis writes ("Re: [PATCH v5 10/11] arm/libxl: Emulated PCI device tree node in libxl"): >> Now you suggest to add a new field arm_vpci in libxl__domain_create_state. > > Hi. I was handwaving, hence "probably" :-). I hadn't actually looked > at the existing code to see precisely how it would fit. > >> Once we have done that I will need to access this structure to know if I need >> to add the DT part and somehow to give it a value depending something which >> for now would the number of pcidevs as there will be no user parameter anymore. > > Right. > > I looked at libxl_arm.c again: > > It seems that the main entrypoint to all this is libxl__prepare_dtb, > and it is that function you want to do new stuff. That gets > libxl_domain_build_info (which is specified by the IDL and comes from > outside libxl, subject to libxl's default-filling machinery) and > libxl__domain_build_state (which is the general state struct). > > The information you need is is libxl_domain_create_info. > libxl__domain_config_setdefault already arranges to set > c_info->passthrough based on the number of PCI PT devices > (search for `need_pt` in libxl_create.c). > > That is, as I understand it on ARM vpci should be enabled if > passthrough is enabled and not otherwise. That is precisely what > the variable c_info->passthrough is. On Arm, c_info->passthrough is also set when assigning platform devives (e.g. a non-PCI network card). At least for now, we don't want to create a node for vCPI in the Device-Tree because we don't enable the emulation. So... > > There is a slight issue because of the distinction between create_info > and build_info and domain_config (and, the corresponding _state) > structs. Currently the DT code ony gets b_info, not the whole > libxl_domain_config. These distinctions largely historical nowadays. > Certainly there is no reason not to pass a pointer to the whole > libxl_domain_config, rather than just libxl_domain_build_info, into > libxl__arch_domain_init_hw_description. > > So I think the right approach for this looks something like this: > > 1. Change libxl__arch_domain_init_hw_description to take > libxl_domain_config* rather than libxl_domain_build_info*. > libxl_domain_config contains libxl_domain_build_info so > this is easy. > > If you put in a convenience alias variable for the > libxl_domain_build_info* you can avoid extra typing in the function > body. (If you call the convenience alias `info` you won't need to > change the body at all, but maybe `info` isn't the best name so you > could rename it to `b_info` maybe; up to you.) > > 2. Make the same change to libxl__prepare_dtb. > > 3. Now you can use d_config->c_info.passthrough to gate the addition > of the additional stuff to the DT. Ie, that is a respin of this > patch 3/3. ... we will need to check d_config->num_pcidevs for the time being. Cheers, -- Julien Grall