virtualbox.org

will there be an option equivalent to the bios440.filename feature on vmware, so that one could run a custom bios,rom file.

Can you explain this feature a little bit more? In general you can use your own BIOS of course when you recompile VBox but you are probably looking for an easy to use option which we currently don't provide.

Frank, this is a feature where you can specify a custom BIOS because the virtualisation abstraction model sets below the BIOS in VMware.

In VBox the BIOS really sits below the abstraction model. It is in effect part of the guest additions, and this is one of the reasons that VBox performs so well. So no, I do not envisage this functionality being added to VBox in the near or medium term. However, as Frank says, the architecture of VBox is such that you can always customise the OSE version to tailor the BIOS functionality to your needs.

So this is exactly what I thought but, to correct Terry's answer, the BIOS is not part of the guest additions (this term is reserved for a software bundle containing some OS-specific drivers). Rather the BIOS is mapped into the physical address space of the guest. But this is a technical detail not very important for this question.

Frank, thanks for correcting me and avoiding any confusion here.

What I meant by the BIOS being in effect (rather than in actuality) part of the guest additions was that is was a piece of VMM aware code that also exploited the HGCM paravirtualisation to remove much of the virtualisation overhead in the BIOS functions.

However looking over the BIOS code again my recollection was entirely wrong. The BIOS is a straight x86-16bit (that is real mode) piece of code, that uses absolutely no paravirtualisation at all and because it is real mode it will be handled by the QEMU real mode interpreter bits of the VMM. So what this all means is that any code calling the VBox machine BIOS frequently will run like dog. Hummmnnn. Isn't it worth a revisit of this design decision -- at least for the key entry points that are called from some of the current OSs?

But this is at least good news for denzo. It make it a lot easier for him to mod an OSE version and swap in his own BIOS if he wants to.

The BIOS has to be 16 bit of course to be compatible with native machines. Every PC (even the newest and fastest Xeon ones) boot in 16-bit mode and I'm sure you can even boot MS-DOS on those machines. Apart from this, the BIOS is rarely more used than for initial booting, that is, find the boot sector, find and initialize all attached devices. Most guests will use their own functions to talk directly to the (virtual) hardware.

Frank wrote:Every PC (even the newest and fastest Xeon ones) boot in 16-bit mode...

Yes, but you are talking about how real machines bootstrap, including POST, initialising devices such as kekboards, etc. However, our BIOS will never have to cold boot; it will only be run inside a VM and so there is nothing to stop us taking advantage of the HGCM is there?

Frank wrote:Apart from this, the BIOS is rarely more used than for initial booting, that is, find the boot sector, find and initialize all attached devices. Most guests will use their own functions to talk directly to the (virtual) hardware.

I agree that there is little point in changing the code that is used once during the boot sequence. So what if this adds 10mS or whatever to the start up. Yes, Linux and NT family OSs now replace most BIOS functions with their own 32-bit/64-bit native device drivers, but there is a big difference between "most functions" and "all functions". Do we instrument BIOS calls to make sure that most doesn't in fact equal 98%, but that those other 2% are being hammered and this is killing our system performance. For example, I came across somewhere an anecdotal statement that if you've migrated a halmacpi.dll CPU to VBox then as part of its reversion it polls the BIOS. This is enough to cause a 2x slow down. Is this correct?

Well, since Qemu can load custom BIOSes (if you want you can have 2 VMs with 2 diffrent BIOSes run simultaneously), there is no reason why VirtualBox can't do the same.

The only problem is that BIOS in VBox is hidden - I don't even know in which file it sits, while in Qemu it is transparent.

-Technologov

The source code for the BIOS is in src/VBox/Devices/PC/BIOS. The makefile creates pcbios.bin and pcbios-syms.h. The BIOS is then linked into the VBoxDD2 shared library by the make for src/VBox/Devices.

Ahh ok, I see vboxdd2.dll on my Windows Host.

Now if VBox becomes more transparent (like Qemu) in that regard, it may well be possible to use custom BIOSes per VM.

If someone wishes, we can open a feature-request.

I believe that Bochs/Qemu/VBox BIOSes are compatible, and can be interchangebly used.

-Technologov

Opened feature-request:
http://www.virtualbox.org/ticket/1929

-Technologov

I cannot tell a lie. I worked this out by doing a

• findstr /M /S /c:"Sun xVM VirtualBox BIOS" *.*

on my C:\Program Files\Sun\xVM VirtualBox, which took me to the correct make file

I'm sorry but I really don't know what you mean by VBox should become more transparent or VBox is hiding something.

Frank:
In VBox (unlike Qemu) there is no BIOS file. I see this as lack of transparency.

From an architectural view the VBox model could do with being opened up a little. Keeping the BIOS in a separate bin file is one example. Documenting the already fairly Open PDM architectures so that developers can understand how to add their own virtual devices easily is another. The sharp divide between PEUL and OSE is another. Everyone should understand that its Suns choice to keep the RDP, USB, SATA and ISCSI modules closed, but why is it an either / or. In other words at the moment if you want to tweak one line of the OSE source code then you have to forgo these modules, even if you are prepared to abide by the PUEL licence. Why not supply the closed modules as DLLs / SOs or even object libraries so that developers can still build a customised version with the PUEL components included.

Anyway, just some thoughts