Andreas, On 05/11/15 02:09, Andrew Fish wrote: > >> On May 10, 2015, at 4:20 PM, Andreas Galauner <andr...@galauner.de> wrote: >> >> On 10.05.2015 15:32, Cohen, Eugene wrote: >>> I apologize since this was probably not the answer you were looking for. >> >> No worries, it's kind of what I expected. Hence the question about the >> virtual bus. >> What I didn't understand was the Driver Binding protocol just by looking >> at the source. I guess I should've looked a bit more into the specification. >> > > The BDS does a gBS->ConnectController() on the device path for the > boot devices. This causes all the drivers in the chain for the device > to get their Driver Binding Start() function called. > > So the driver gets called on a handle created by a parent bus driver. > The root of the device path chain is always a DXE driver (on a PI > system), and on a PCI this is the PCI Host Bridge.
* I'd like to put emphasis on the above -- the UEFI driver model and the driver binding protocol will work once you have some "input" handles to operate on. A bus driver will then create child handles and install protocol interfaces on the child handles, a device driver will install (a) protocol interface(s) on the input handle itself. Both driver kinds need an "input" handle, and AIUI your question was how to create those "axiomatic" (= not originating from any other handle) / root handles. (Plus, as a technicality, the drivers that use the UEFI driver model don't do the above checks for support & the input handle binding in their entry points. In their entry points they just register instances (usually, one instance) of the driver binding protocol, and member functions of that protocol instance will get callbacks when BDS calls gBS->ConnectController(), as Andrew described.) So, as Andrew says, for producing the various "root handles", you need a DXE driver that incorporates platform specific knowledge, and just goes ahead and creates new handles and installs protocol interfaces on them in the driver entry point (ie. it would expressly not follow the UEFI driver model). * You can see one example for this here: ArmPlatformPkg/ArmVirtualizationPkg/VirtFdtDxe/ This DXE driver runs in QEMU and Xen virtual machines (ARM and AARCH64 guest architecture). It parses a DTB (device tree binary) that originates from the hypervisor, in order to locate the various (virtual) MMIO devices. Relevant for your question, for each "virtio,mmio"-compatible device, VirtFdtDxe creates a new handle (which occurs by simply installing the first protocol interface on an initially NULL handle -- and in this case this first installed protocol happens to be EFI_DEVICE_PATH_PROTOCOL). Then VirtFdtDxe calls the VirtioMmioInstallDevice() function, defined in OvmfPkg/Library/VirtioMmioDeviceLib/ which function installs the (non-standard) VIRTIO_DEVICE_PROTOCOL on the same handle. Once this is done, the new handle with the EFI_DEVICE_PATH_PROTOCOL and the VIRTIO_DEVICE_PROTOCOL instances on it becomes "eligible" for UEFI driver model drivers (device drivers and bus drivers alike) to check it for supportability and to bind it if supported. Strictly speaking, VirtFdtDxe is *not* a bus driver, in the UEFI driver model terminology, because: - it doesn't implement the driver binding protocol, - so the member functions in question don't exit, and don't take an input handle each, - VirtFdtDxe does its job directly in its entry point. On the other hand, you could call VirtFdtDxe a "synthetic bus driver" (I'm avoinding the word "virtual" here because it's quite overloaded), in the sense in which you and Eugene originally used the expression -- VirtFdtDxe produces the various root handles out of "nothing" (ie. platform specific information). * Another example: Andrew mentioned PCI Host Bridge. The edk2 tree contains at least two implementations: PcAtChipsetPkg/PciHostBridgeDxe/ ArmPlatformPkg/ArmVirtualizationPkg/PciHostBridgeDxe/ (The latter is a port of the former.) They are DXE_DRIVER modules, not UEFI_DRIVER modules; they don't follow the UEFI driver model. They produce their root handles and the respective protocol interfaces "out of nothing" (ie. not deriving them from other handles & protocols). Whereas the PCI bus driver in MdeModulePkg/Bus/Pci/PciBusDxe/ is a UEFI bus driver that produces (enumerates) child handles (with PciIo protocol instances on them) by binding the Pci Root Bridge Io protocol instances produced by the above host bridge drivers. Thanks Laszlo > Thus for a PCI driver it looks to match PCI device type, in driver > binding supported. And if supported passes, then the Start() will get > called. > > Thanks, > > Andrew Fish > >> >>> Let me know if you're interested in taking this on. >> >> Puh, I'm pretty now to UEFI and have to understand the internals a bit >> more. I think I'll just finish my current port for now and slowly dig >> deeper into UEFI. Maybe I'll take this challenge after that. >> This whole thing was intended to be a 1-to-2-weekends-pet-project in the >> beginning. But thanks for the offer! >> >> Thanks, >> - Andy >> >> ------------------------------------------------------------------------------ >> One dashboard for servers and applications across Physical-Virtual-Cloud >> Widest out-of-the-box monitoring support with 50+ applications >> Performance metrics, stats and reports that give you Actionable Insights >> Deep dive visibility with transaction tracing using APM Insight. >> http://ad.doubleclick.net/ddm/clk/290420510;117567292;y >> _______________________________________________ >> edk2-devel mailing list >> edk2-devel@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/edk2-devel > > > ------------------------------------------------------------------------------ > One dashboard for servers and applications across Physical-Virtual-Cloud > Widest out-of-the-box monitoring support with 50+ applications > Performance metrics, stats and reports that give you Actionable Insights > Deep dive visibility with transaction tracing using APM Insight. > http://ad.doubleclick.net/ddm/clk/290420510;117567292;y > _______________________________________________ > edk2-devel mailing list > edk2-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/edk2-devel > ------------------------------------------------------------------------------ One dashboard for servers and applications across Physical-Virtual-Cloud Widest out-of-the-box monitoring support with 50+ applications Performance metrics, stats and reports that give you Actionable Insights Deep dive visibility with transaction tracing using APM Insight. http://ad.doubleclick.net/ddm/clk/290420510;117567292;y _______________________________________________ edk2-devel mailing list edk2-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/edk2-devel
