422330d4ab
Major changes: 1. Correct handling of device multi-function capability We only check function zero for this feature. If it has it, we continue looking at all remaining functions, ignoring those with invalid vendors. The PCI spec says we are not to probe beyond function zero if it does not exist or indicates it is not a multi-function device. 2a. Walk *ALL* buses in the PCI space, however, Before walking the PCI hierarchy, post-processed ACPI DMAR info is parsed and a map is created between all device-scopes across all DRHDs and the corresponding IOMMU index. This map is used at the time of walking the PCI hierarchy. If a BDF that ACRN is currently working on, is found in the above-mentioned map, the BDF device is mapped to the corresponding DRHD in the map. If the BDF were a bridge type, realized with "Header Type" in config space, the BDF device along with all its downstream devices are mapped to the corresponding DRHD in the map. To avoid walking previously visited buses, we maintain a bitmap that stores which bus is walked when we handle Bridge type devices. Once ACPI information is included into ACRN about the PCI-Express Root Complexes / PCI Host Bridges, we can avoid the final loop which probes all remainder buses, and instead jump to the next Host Bridge bus. From prior patches, init_pdev returns the pdev structure it created to the caller. This allows us to complete initialization by updating its drhd_idx to the correct DRHD. Tracked-On: #4134 Signed-off-by: Alexander Merritt <alex.merritt@intel.com> Signed-off-by: Sainath Grandhi <sainath.grandhi@intel.com> Reviewed-by: Eddie Dong <eddie.dong@intel.com> Reviewed-by: Jason Chen CJ <jason.cj.chen@intel.com> |
||
|---|---|---|
| .. | ||
| acpi_parser | ||
| arch/x86 | ||
| boot | ||
| bsp/ld | ||
| common | ||
| debug | ||
| dm | ||
| hw | ||
| include | ||
| lib | ||
| pre_build | ||
| release | ||
| scenarios | ||
| scripts | ||
| Kconfig | ||
| MAINTAINERS | ||
| Makefile | ||
| README.rst | ||
README.rst
ACRN Hypervisor ############### The open source `Project ACRN`_ defines a device hypervisor reference stack and an architecture for running multiple software subsystems, managed securely, on a consolidated system by means of a virtual machine manager. It also defines a reference framework implementation for virtual device emulation, called the "ACRN Device Model". The ACRN Hypervisor is a Type 1 reference hypervisor stack, running directly on the bare-metal hardware, and is suitable for a variety of IoT and embedded device solutions. The ACRN hypervisor addresses the gap that currently exists between datacenter hypervisors, and hard partitioning hypervisors. The ACRN hypervisor architecture partitions the system into different functional domains, with carefully selected guest OS sharing optimizations for IoT and embedded devices. You can find out more about Project ACRN on the `Project ACRN documentation`_ website. .. _`Project ACRN`: https://projectacrn.org .. _`ACRN Hypervisor`: https://github.com/projectacrn/acrn-hypervisor .. _`Project ACRN documentation`: https://projectacrn.github.io/