From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received-SPF: Pass (sender SPF authorized) identity=mailfrom; client-ip=66.187.233.73; helo=mx1.redhat.com; envelope-from=lersek@redhat.com; receiver=edk2-devel@lists.01.org Received: from mx1.redhat.com (mx3-rdu2.redhat.com [66.187.233.73]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ml01.01.org (Postfix) with ESMTPS id 35CD721FB7D45 for ; Tue, 3 Apr 2018 03:36:17 -0700 (PDT) Received: from smtp.corp.redhat.com (int-mx05.intmail.prod.int.rdu2.redhat.com [10.11.54.5]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 0C8E44070214; Tue, 3 Apr 2018 10:36:16 +0000 (UTC) Received: from lacos-laptop-7.usersys.redhat.com (ovpn-120-185.rdu2.redhat.com [10.10.120.185]) by smtp.corp.redhat.com (Postfix) with ESMTP id 61D817C25; Tue, 3 Apr 2018 10:36:09 +0000 (UTC) To: "Tiger Liu(BJ-RD)" Cc: "'edk2-devel@lists.01.org'" , Anthony Perard , Julien Grall , Marcel Apfelbaum References: From: Laszlo Ersek Message-ID: Date: Tue, 3 Apr 2018 12:36:09 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: X-Scanned-By: MIMEDefang 2.79 on 10.11.54.5 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.11.55.5]); Tue, 03 Apr 2018 10:36:16 +0000 (UTC) X-Greylist: inspected by milter-greylist-4.5.16 (mx1.redhat.com [10.11.55.5]); Tue, 03 Apr 2018 10:36:16 +0000 (UTC) for IP:'10.11.54.5' DOMAIN:'int-mx05.intmail.prod.int.rdu2.redhat.com' HELO:'smtp.corp.redhat.com' FROM:'lersek@redhat.com' RCPT:'' Subject: Re: OVMF package : Question about Qemu/Xen support X-BeenThere: edk2-devel@lists.01.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: EDK II Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Apr 2018 10:36:17 -0000 Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Hi, (CC Marcel) On 04/02/18 08:55, Tiger Liu(BJ-RD) wrote: > Hi, Laszlo: > I have a question you would like to ask you. > Could I study pcie native hot plug feature with ovmf? > > It seems qemu emulates Q35 chipset. > And ovmf provides PciHotPlugInitDxe driver. Sure. Here's some tips I can give you: * The first PCI Express -- not traditional PCI -- hotplug feature request for OVMF arrived in . That link is dead now, because we abandoned the GitHub issue tracker. Instead, the report was migrated to . This issue got solved by adding MMCONFIG (ECAM) config space access to OVMF. Without MMCONFIG, PCIe hotplug in the guest OS would not work. Please see Marcel's analysis in the TianoCore BZ linked above. The edk2 commit range is noted in comment 32. * Once config space access works like that, you need the PCIe enumeration / resource assignment (which occurs in the firmware) to account for PCI resources *in advance* that hotplugged endpoints *might* require. This means reserving various kinds of apertures. On the QEMU side, this is documented in the following two text files (in the QEMU tree): - docs/pcie.txt - docs/pcie_pci_bridge.txt In particular there is a "resource reservation hint" PCIe capability (for PCIe root ports) that QEMU can populate and OVMF can parse. Then OVMF informs PciBusDxe to reserve the appropriate resources. * PCI_HOT_PLUG_INIT_PROTOCOL (implemented in OVMF by OvmfPkg/PciHotPlugInitDxe) is defined by the PI spec. Roughly, it has two purposes: it can (a) report+initialize non-enumerable [*] hotplug controllers (of which QEMU has none) to PciBusDxe, (b) it can convey reservation hints ("resource paddings") to PciBusDxe. OVMF stubs out the two interfaces related to purpose (a), and implements the GetResourcePadding() member function (purpose (b)) by translating QEMU's PCIe capability to the format expected by the PI spec and PciBusDxe. [*] The PI spec calls this kind of hotplug controller "root" HPC, but that has nothing to do with "root" in the PCIe sense. In this terminology, "root HPC" simply means "non-enumerable", and "non-root HPC" means "enumerable" through the normal PCI(e) traversal. Hope this helps, Laszlo