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 165B2C433FE for ; Thu, 7 Oct 2021 16:12:13 +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 CEE796105A for ; Thu, 7 Oct 2021 16:12:12 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org CEE796105A Authentication-Results: mail.kernel.org; dmarc=pass (p=none dis=none) header.from=xenproject.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=lists.xenproject.org Received: from list by lists.xenproject.org with outflank-mailman.203838.358982 (Exim 4.92) (envelope-from ) id 1mYVzw-0001cB-2y; Thu, 07 Oct 2021 16:11:56 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 203838.358982; Thu, 07 Oct 2021 16:11:56 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1mYVzv-0001c4-Vn; Thu, 07 Oct 2021 16:11:55 +0000 Received: by outflank-mailman (input) for mailman id 203838; Thu, 07 Oct 2021 16:11:54 +0000 Received: from mail.xenproject.org ([104.130.215.37]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1mYVzu-0001by-HE for xen-devel@lists.xenproject.org; Thu, 07 Oct 2021 16:11:54 +0000 Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1mYVzu-0007hB-5u for xen-devel@lists.xenproject.org; Thu, 07 Oct 2021 16:11:54 +0000 Received: from iwj (helo=mariner.uk.xensource.com) by xenbits.xenproject.org with local-bsmtp (Exim 4.92) (envelope-from ) id 1mYVzu-0002YI-59 for xen-devel@lists.xenproject.org; Thu, 07 Oct 2021 16:11:54 +0000 Received: from iwj by mariner.uk.xensource.com with local (Exim 4.89) (envelope-from ) id 1mYVzn-0006tj-W3; Thu, 07 Oct 2021 17:11:48 +0100 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=xenproject.org; s=20200302mail; h=References:In-Reply-To:Subject:Cc:To:Date :Message-ID:Content-Transfer-Encoding:Content-Type:MIME-Version:From; bh=bNKObHLvuYHl9RRVVlwnULETAyQzOqANMlh/V3j4NUM=; b=x2K4LBapGsb4ob13njGRroJD4o EwY1uEcRVMTfnhUgl4LPrZc3j5Rz4mdfjI09U+QklBMAyc6GqBcjw4Jpo3uuf33Tr6zDi/3Rvgdv8 /YPFge6YmpCZnFI7ngx7WYoaBoH28JGIFA9FPABvsIKNQyVtZKUD84OyiRbzshZ/EFYA=; From: Ian Jackson MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <24927.7235.736221.270358@mariner.uk.xensource.com> Date: Thu, 7 Oct 2021 17:11:47 +0100 To: Rahul Singh Cc: Ian Jackson , Julien Grall , xen-devel , Bertrand Marquis , Andre Przywara , Wei Liu , Anthony PERARD , Juergen Gross , Stefano Stabellini , Volodymyr Babchuk Subject: Re: [PATCH v5 10/11] arm/libxl: Emulated PCI device tree node in libxl In-Reply-To: <294BE20A-7E45-405C-BC19-C292295E85E3@arm.com> References: <7bdac405-a889-15e1-be19-5876f7253855@xen.org> <24926.53690.621007.507249@mariner.uk.xensource.com> <294BE20A-7E45-405C-BC19-C292295E85E3@arm.com> X-Mailer: VM 8.2.0b under 24.5.1 (i686-pc-linux-gnu) Rahul Singh writes ("Re: [PATCH v5 10/11] arm/libxl: Emulated PCI device tree node in libxl"): > As Stefano suggested in another email that we can remove the vpci > option, if we reach to conclusion that we need vpci option I will > move it to internal structure. ... > Yes I agree with you VPCI is necessary for hot plugged PCI device > and once we implement the hotplug in future we will use the > passthrough= option to enable VPCI. So, to summarise, I think the situation is: * VCPI is necessry for passthrough on ARM, whether coldplug or hotplug. It's part of the way that PCI-PT works on ARM. * Hotplug is not yet implemented. * VPCI is not necessary on x86 (evidently, since we don't have it there but we do have passthrough). So when hotplug is added, vpci will need to be turned on when passthrough=yes is selected. I don't fully understand the other possible values for passthrough= but maybe we can defer the question of whether they apply to ARM ? I think that means that yes, this should be an internal variable. Probably in libxl__domain_create_state. We don't currently arrange to elide arch-specific state in there, so perhaps it's fine just to invent a member called `arm_vpci`. Maybe you could leave a comment somewhere so that if and when PCI PT hotplug is implemented for ARM, the implementor remembers to wire this up. Ian.