On 03/31/14 16:58, Paolo Bonzini wrote: > In many cases, the second node in /pci@i0cf8/XYZ@DD,FF node is enough > to match a UEFI device path; a typical cases is a NIC that is assigned > from the host to the guest. Add a catch-all case for PCI devices, and > reuse it for NICs since it works well for those too. > > Contributed-under: TianoCore Contribution Agreement 1.0 > Signed-off-by: Paolo Bonzini <[email protected]> > --- > OvmfPkg/Library/PlatformBdsLib/QemuBootOrder.c | 24 +++++++----------------- > 1 file changed, 7 insertions(+), 17 deletions(-) > > diff --git a/OvmfPkg/Library/PlatformBdsLib/QemuBootOrder.c > b/OvmfPkg/Library/PlatformBdsLib/QemuBootOrder.c > index 7f81fc3..bd0fb76 100644 > --- a/OvmfPkg/Library/PlatformBdsLib/QemuBootOrder.c > +++ b/OvmfPkg/Library/PlatformBdsLib/QemuBootOrder.c > @@ -763,37 +763,27 @@ TranslateOfwNodes ( > TargetLun[0], > TargetLun[1] > ); > - } else if (NumNodes >= 3 && > - SubstringEq (OfwNode[1].DriverName, "ethernet") && > - SubstringEq (OfwNode[2].DriverName, "ethernet-phy") > - ) { > + } else { > // > - // OpenFirmware device path (Ethernet NIC): > + // Generic OpenFirmware device path for PCI devices: > // > - // /pci@i0cf8/ethernet@3[,2]/ethernet-phy@0 > - // ^ ^ ^ > - // | | fixed > + // /pci@i0cf8/ethernet@3[,2] > + // ^ ^ > // | PCI slot[, function] holding Ethernet card > // PCI root at system bus port, PIO > // > // UEFI device path prefix (dependent on presence of nonzero PCI > function): > // > - // PciRoot(0x0)/Pci(0x3,0x0)/MAC(525400E15EEF,0x1) > - // PciRoot(0x0)/Pci(0x3,0x2)/MAC(525400E15EEF,0x1) > - // ^ ^ > - // MAC address IfType (1 == Ethernet) > - // > - // (Some UEFI NIC drivers don't set 0x1 for IfType.) > + // PciRoot(0x0)/Pci(0x3,0x0) > + // PciRoot(0x0)/Pci(0x3,0x2) > // > Written = UnicodeSPrintAsciiFormat ( > Translated, > *TranslatedSize * sizeof (*Translated), // BufferSize in bytes > - "PciRoot(0x0)/Pci(0x%x,0x%x)/MAC", > + "PciRoot(0x0)/Pci(0x%x,0x%x)", > PciDevFun[0], > PciDevFun[1] > ); > - } else { > - return RETURN_UNSUPPORTED; > } > > // >
(1) What is the OFW format that qemu produces for a passthru (=host) device? If it has a third node, I think I'd prefer a specific check. If it only comes with two nodes (and we want to be able to match it), then the catchall is unavoidable. (2) The next question is, can something break if we drop the MAC part from the UEFI devpath fragment where we used to specify it. In other words, if we rely on the catchall to recognize an emulated NIC. In theory, breakage would be possible by (2a) recognizing something we shouldn't, (2b) not recognizing something we should. We're safe wrt. 2b, because the MAC at the same PCI device & function will stay there. Hence the new (shorter) UEFI devpath fragment should match the full UEFI devpath that the longer fragment (with the MAC part) used to match. OK. Ad 2a, the PCI (device, function) pair is unique (we ignore buses and certainly domains). So the shorter UEFI devpath fragment shouldn't match anything else than it matched before. What if we change the PCI device/function address of some other (non-Ethernet) device? Then the new address could only take the Ethernet device's original address if we moved the Ethernet device elsewhere too, on the qemu command line. But, in that case the bootindex flag will accompany the Ethernet device to the Ethernet device's new address too, meaning that the OFW devpath will reflect the new spot of the Ethernet device too. So, I think: - The patch should be safe. - But, for consistency with the rest of the code, I'd prefer a more complete parsing of the passthru OFW devpath -- if that's possible. If not, then the patch seems OK. The SetBootOrderFromQemu() function dumps the entire "bootorder" fw_cfg file (on DEBUG_VERBOSE level). This should allow you to determine the complete format of the OFW entry corresponding to the passthru device. (I guess it can be figured out from the qemu source as well, but last time I looked at that node-wise OFW path composition, I gave up.) Thanks Laszlo ------------------------------------------------------------------------------ _______________________________________________ edk2-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/edk2-devel
