[feature-request] Allow Custom, per-VM BIOS

[Technologov]

Hi All,

Since VBox BIOS is based on Qemu (and Bochs) BIOS, I believe there is no need to hide (encapsulate) VBox BIOS into other files.

I think it would be best to have transparent access to separate BIOS file, and allow different BIOSes for each VM for advanced users.

This feature request is actually 2:

1. BIOS should be 1 separate file (for transparency)

2. Per-VM BIOS file must be configurable (like Qemu)

-Technologov, 8.8.08 !

[cakruege]

Even in closed source products like vmware you can change the bios. The original one is buld in but you can specify another one in settings.

Please ad this

[Mitch Bradley]

It appears that this feature - the ability to specify a different BIOS image - already exists. Here is how you can specify a different BIOS image for virtual machine "MyVM":

VBoxManage setextradata MyVM "VBoxInternal/Devices/pcbios/0/Config/BiosRom" "c:\mybios.rom"

I don't know the default search patch for the file, so I ended up having to specify the full path name.

Using this technique, I managed to get VirtualBox to execute my ROM code, but there is a problem - the ROM image must be exactly 64K. If the ROM image is not a multiple of 64K, VirtualBox (version 2.1.0) falls back to the built-in BIOS image.

If the ROM image is a multiple of 64K and larger than 64K, VirtualBox aborts. The log message says:

PDM: Failed to construct 'pcibios/0! VERR_PGM_HANDLER_PHYSICAL_CONFLICT (-1603) - Attempt to register an access handler for a physical range of which a part was already handled.

By examining logs under other circumstances and reading the code in DevPcBios.cpp (round about line 1614), I have a guess about what is going on:

If the image is larger than 64K, the code in DevPcBios.cpp tries to map the last 128K of the BIOS image at address range 0xe0000 .. 0xfffff (and it would also try to map the whole image at the very top of physical address space, e.g. at 0xfff80000 .. 0xffffffff for a 512K image). However, there is already something in the 0xeXXXX range, specifically:

e0000 - e0fff ACPI RSDP
e1000 - e1fff DMI tables
e2000 - edfff Net Boot ROM

So it would appear that DevPcBios.cpp needs to be a bit more subtle about mapping the last 128K. Perhaps the ACPI, DMI, and Net Boot stuff should be discarded if a custom ROM overlays those areas, under the assumption that if you are going to take over the BIOS, it is your responsibility to supply that functionality.

Mitch Bradley

[Mitch Bradley]

There is a "quick fix" that would probably work to enable > 64K BIOS images, assuming that such images don't need the low-meg mapping in the 0xeXXXX range:

DevPcBios.cpp line 1613 says:

cb = RT_MIN(cbPcBiosBinary, 128 * _1K); /* Effectively either 64 or 128K. */

Replacing 128 with 64 would eliminate the (failing) attempt to map the already-populated 0xeXXXX range, while retaining the important mapping to the 0xfffXXXXX range.

Firmware like Open Firmware and Coreboot don't need the low-meg footprint, so the quick fix would probably enable their use.

[Stuart]

Just out of curiosity has anyone actually gotten this to work?

A friend in formed me that As far as he could see it seems to act anomalously when trying commercial bioses, and would appear conspicuously dysfunctional and defective.

[Stuart]

I just see some change was made to this ticket, while it might in fact be reasonable to split this into two features, what remains is the question: what work has transpired in pursuance of actualizing these features in either case?