On Thu, 2013-02-14 at 16:46 +0000, Ian Campbell wrote:
On Thu, 2013-02-14 at 14:23 +0000, David Woodhouse wrote:
git.infradead.org/users/dwmw2/seabios.git
There's a README.CSM file in the SeaBIOS tree which describes how to build OVMF with CSM support.
Do I understand correctly from the README that once CSM support is enabled at build time you can choose to use it dynamically at boot time? If so, Neat!
Right. It's just another boot target. The UEFI device path for each of the bot targets, and the bootorder variable which sets their relative priorities, are stored in persistent nvram storage...
I suppose this selection is persistent for a given VM, but where is it saved?
That's another item on my TODO list. On real hardware it's actually stored in flash. On OVMF we don't have an answer. There's a dirty hack which stores them in a *file* on the EFI system partition, but that really isn't very helpful it stops working when the OS calls ExitBootServices — because you can't be touching the file system at the same time the OS might be. So when an OS installer does its install and then sets the NV variables to boot into the newly-installed OS... it can't work.
There was some initial work on supporting -pflash for qemu on i386 and working exactly like real hardware does — which meant firmware upgrades had to be done the same way since the firmware and the variables were all in the same image. And it didn't work with KVM.
I'm looking at fixing this to use a flash device *other* than the one that the firmware runs from, adjacent to it at the top of memory. Or something like that. But it's not quite solved yet. It'll *need* to be, for OVMF to be usable in the general case. And then it's solved automatically for CSM too.