I have been experimenting with Workstation Pro 15.5.6 and it's implementation of UEFI and the UEFI Shell (currently 2.31) to develop and test UEFI drivers and applications. I was wondering if there might be a relatively easy way to change the firmware, or components of it, on a VM-by-VM basis? That is, I'd like VM1 to boot with EFI64-1.ROM, VM2 to boot with EFI64-2.ROM while remaining and new VMs would use the standard EFI64.ROM as distributed with Workstation Pro.
I'm using EDK2 to compile the applications, drivers and roms. I do use QEMU for this but, without getting into detail, I'd like to use Workstation Pro as the principal development environment.
Thank you for any help or thoughts.
Changing the firmware ROM image can be done using the efi64.filename config option in the .vmx file:
efi64.filename = "/path/to/my/EFI64.ROM"
If you are using a 32-bit guestOS type, you should instead use:
efi32.filename = "/path/to/my/EFI32.ROM"
That will allow you to (for example) use the EFI firmware from earlier releases of our products or use the firmware from ESXi. (It goes without saying that this is not a configuration which we officially support, but it absolutely should work...)
That option can go into the per-VM .vmx file but it can also go into the global and user configuration files if you want to make a change more widely – refer to the start of a vmware.log for the specific paths examined.
Building your own firmware based upon EDK2 would be challenging because of some hypervisor-specific stuff which isn't in EDK2. It might be possible to produce some basic firmware which works under limited circumstances – e.g. fake or no support for EFI Variable services, limited support for booting ACPI guest OSes, likely no support for CPU or PCI[e] hotplug, etc...
We do not provide any facility to substitute parts of our firmware with ones of your own making. You may be able to make creative use of publicly available firmware-editing tools to achieve your goals though. (Disclaimer: I know they exist, but I have not needed to use them, so I can not really assist with their use.) (And it goes without saying that this is waaaaaaay beyond the boundaries of what we officially support...)
Getting your own applications/drivers into the VM should be "straightforward". I usually just use a floppy disk image written with mtools on the host, or you can make your own CD images, or mount the virtual hard disk and copy things onto it, etc.
Let me know if you run into any trouble (beyond that you have already mentioned in your other thread)...
--
Darius
Changing the firmware ROM image can be done using the efi64.filename config option in the .vmx file:
efi64.filename = "/path/to/my/EFI64.ROM"
If you are using a 32-bit guestOS type, you should instead use:
efi32.filename = "/path/to/my/EFI32.ROM"
That will allow you to (for example) use the EFI firmware from earlier releases of our products or use the firmware from ESXi. (It goes without saying that this is not a configuration which we officially support, but it absolutely should work...)
That option can go into the per-VM .vmx file but it can also go into the global and user configuration files if you want to make a change more widely – refer to the start of a vmware.log for the specific paths examined.
Building your own firmware based upon EDK2 would be challenging because of some hypervisor-specific stuff which isn't in EDK2. It might be possible to produce some basic firmware which works under limited circumstances – e.g. fake or no support for EFI Variable services, limited support for booting ACPI guest OSes, likely no support for CPU or PCI[e] hotplug, etc...
We do not provide any facility to substitute parts of our firmware with ones of your own making. You may be able to make creative use of publicly available firmware-editing tools to achieve your goals though. (Disclaimer: I know they exist, but I have not needed to use them, so I can not really assist with their use.) (And it goes without saying that this is waaaaaaay beyond the boundaries of what we officially support...)
Getting your own applications/drivers into the VM should be "straightforward". I usually just use a floppy disk image written with mtools on the host, or you can make your own CD images, or mount the virtual hard disk and copy things onto it, etc.
Let me know if you run into any trouble (beyond that you have already mentioned in your other thread)...
--
Darius
Thank you very much for your helpful answer! I thought I'd tried the efi64.filename route, but as I recall, Workstation removed the entry from the vmx file. I'll try it again.
The rest of your answer makes good sense. I certainly wasn't expecting official support for any of this but thought there might be other users who had tinkered with the possibilities. Your response(s) far surpass my expectations officially. Thanks so much for the extremely helpful hints
I have been able to load custom drivers and applications successfully from the ESP with no trouble (aside from programmer error!). I sense I shouldn't try to draw you into my schemes any further.
May I ask, does the stock firmware ever call ExitBootServices() itself? I assume it relies on the OS Loader or the OS to do that.
Many thanks for your help.
I thought I'd tried the efi64.filename route, but as I recall, Workstation removed the entry from the vmx file.
Workstation will remove it from the vmx file if (and only if) Workstation itself has the VM "open" when you made the edits – i.e. if the VM is running and/or there is a configuration/management dialog or window/tab open for the VM. In essence it never automatically removes stuff you add (except for a handful of special config options which activate once and then delete themselves, but those are just a few weird ones), however it might innocently overwrite your edited file with a new version which lacks your edits, based upon its outdated record of what the file contained earlier on. If you close all of the dialogs/tabs/whatever for that VM (or, in stubborn cases, exit out of Workstation entirely), it won't have any outdated record of the file's contents and it won't overwrite your edits.
I sense I shouldn't try to draw you into my schemes any further.
A bit of mild scheming is always entertaining. :smileycool:
May I ask, does the stock firmware ever call ExitBootServices() itself? I assume it relies on the OS Loader or the OS to do that.
Only the OS loader (or an arbitrary EFI application which pretends it's an OS loader) calls ExitBootServices; The firmware provides the implementation of ExitBootServices but does not itself include any code which can call it.
--
Darius