On 11/01/13 21:46, Andrew Fish wrote: > > On Nov 1, 2013, at 2:34 AM, Andrew fish <af...@apple.com > <mailto:af...@apple.com>> wrote: > >> A separate FD would be the easiest way to deal with this. You could >> have an installer step in the build that only copies over the NV >> storage FD if it does not exist. >> >> You guys should also implement the PXE UUID as a different UUID per >> installation. >> >> > > This is the UUID I was talking about. It is in the SMBIOS TYPE 1 record. > > https://svn.code.sf.net/p/edk2/code/trunk/edk2/MdeModulePkg/Library/DxeNetLib/DxeNetLib.c > > CopyMem (SystemGuid, &Smbios.Type1->Uuid, sizeof (EFI_GUID));
The official / committed OvmfPkg code has no support for SMBIOS. The code you're referring to (function NetLibGetSystemGuid()) should return EFI_NOT_FOUND early, before reaching the CopyMem() above, right after EfiGetSystemConfigurationTable(). The SMBIOS patches that I had posted earlier for OVMF <http://thread.gmane.org/gmane.comp.bios.tianocore.devel/3037> implement the following logic for the UUID field in the Type 1 record: (1) If qemu provides a complete Type 1 table (including the UUID field), install it. Otherwise, use a default (built-in) OVMF table, with the following overrides: (2a) Load the UUID from qemu, from the the dedicated UUID fw_cfg file, (2b) then, if qemu provides a field-level override for Type1.UUID, use that instead. > It should be unique per platform. The universally used management toolstack for qemu, libvirt, generates a unique UUID for each virtual machine at creation time, and this UUID remains persistent for the VM. (It is saved in the VM config XML file). When starting the VM, libvirt passes this UUID to qemu on the command line, and then it is available to OVMF too. > The idea is the PXE Server can make a > policy decision on what image to serve back to a particular machine. So > for example if you had a bunch of OVMF instances set up for testing, you > could teach the PXE Server the UUID of a specific machine and serve back > a specific OS (or even version of an OS) installer in response to the > PXE boot to automate testing. > > Folks have botched this in the real world and return back the same UUID > for a class of machines, so it would be good to make sure each OVMF > instance is unique, but does not change from build to build. So this > UUID would be something that would get preserved like the NV Storage, so > probably good to design in a solution for the UUID when fixing the NVRAM > storage issue. According to the above, the UUID is VM specific, permanent, stored on the host side in the VM config XML, and independent of the OVMF build. The host administrator can edit the UUID if necessary. I believe that should mostly accommodate your recommendation, shouldn't it? Thank you! Laszlo ------------------------------------------------------------------------------ Android is increasing in popularity, but the open development platform that developers love is also attractive to malware creators. Download this white paper to learn more about secure code signing practices that can help keep Android apps secure. http://pubads.g.doubleclick.net/gampad/clk?id=65839951&iu=/4140/ostg.clktrk _______________________________________________ edk2-devel mailing list edk2-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/edk2-devel