Add the OVMF UEFI support to hvmloader

A way to integrate OVMF build directly into XEN has still be discussed on the mailing list appropriately.

Quoted 3 lines · Attilio Rao

A way to integrate OVMF build directly into XEN has still be discussed on the mailing list appropriately.

AIUI OVMF is maintained in SVN. Our normal procedure for adding an external dependency would be for us to mirror it on xenbits as a convenience to our users, who don't need to get stuff from multiple places, and as a courtesy to our upstreams, so our users don't consume their resources.

I don't much fancy setting the necessary webdav or whatever stuff on xenbits and integrating SVN support into our build system though. What do people think about using git-svn to manage our mirror in git instead? Or better: perhaps OVMF have an official git or hg mirror?

Anyone have any thoughts/opinions/better ideas etc?

Quoted 5 lines

diff -r a88ba599add1 -r 032fea10f8d1 tools/firmware/hvmloader/config.h

tools/firmware/hvmloader/config.h +0 -0

@@ -35,6 +35,8 @@ struct bios_config {
 

tools/firmware/hvmloader/config.h struct bios_config { · line 40

Quoted 5 lines

tools/firmware/hvmloader/config.h +2 -0

  extern struct bios_config rombios_config;
  extern struct bios_config seabios_config;
+extern struct bios_config ovmf32_config;
+extern struct bios_config ovmf64_config;
 

Can you confirm that you need an OVMF which matches the OS bit-width you are installing. i..e that there is no support for booting a 32 bit EFI OS (or bootloader, shell, whatever it is called) on a 64 bit OVMF?

[...]

tools/firmware/hvmloader/config.h

Quoted 9 lines

tools/firmware/hvmloader/config.h +8 -0

+static void ovmf_acpi_build_tables(void)
+{
+    struct acpi_config config = {
+        .dsdt_anycpu = dsdt_anycpu,
+        .dsdt_anycpu_len = dsdt_anycpu_len,
+        .dsdt_15cpu = dsdt_15cpu,
+        .dsdt_15cpu_len = dsdt_15cpu_len,
+    };

IIRC the 15cpu tables are there to workaround a bug in some old version of Windows (2k?). I think therefore you can omit these on the basis that no version of Windows with that bug also supports EFI. seabios.c does this too.

Quoted 24 lines · Ian Campbell

Quoted 3 lines · Attilio Rao

A way to integrate OVMF build directly into XEN has still be discussed on the mailing list appropriately.

AIUI OVMF is maintained in SVN. Our normal procedure for adding an external dependency would be for us to mirror it on xenbits as a convenience to our users, who don't need to get stuff from multiple places, and as a courtesy to our upstreams, so our users don't consume their resources.

I don't much fancy setting the necessary webdav or whatever stuff on xenbits and integrating SVN support into our build system though. What do people think about using git-svn to manage our mirror in git instead? Or better: perhaps OVMF have an official git or hg mirror?

Anyone have any thoughts/opinions/better ideas etc?

Quoted 5 lines

diff -r a88ba599add1 -r 032fea10f8d1 tools/firmware/hvmloader/config.h

tools/firmware/hvmloader/config.h +0 -0

@@ -35,6 +35,8 @@ struct bios_config {
 

Quoted 10 lines

tools/firmware/hvmloader/config.h struct bios_config { · line 40

Quoted 5 lines

tools/firmware/hvmloader/config.h +2 -0

  extern struct bios_config rombios_config;
  extern struct bios_config seabios_config;
+extern struct bios_config ovmf32_config;
+extern struct bios_config ovmf64_config;
 

Can you confirm that you need an OVMF which matches the OS bit-width you are installing. i..e that there is no support for booting a 32 bit EFI OS (or bootloader, shell, whatever it is called) on a 64 bit OVMF?

I didn't test this case, really, but I would think OVMF-64 / OS-32 could possibly work.
You are suggesting if this is the case we should just ship the 64-bit emulation?

Quoted 1 line

Quoted 1 line

Attilio Rao <[email protected]> 02/23/12 11:18 AM >>>

Quoted 4 lines · Ian Campbell

On Wed, 2012-02-22 at 19:17 +0000, Attilio Rao wrote:
Can you confirm that you need an OVMF which matches the OS bit-width you are installing. i..e that there is no support for booting a 32 bit EFI OS (or bootloader, shell, whatever it is called) on a 64 bit OVMF?

I didn't test this case, really, but I would think OVMF-64 / OS-32 could possibly work.

Quoted 9 lines

Quoted 1 line

Quoted 1 line

Attilio Rao <[email protected]> 02/23/12 11:18 AM >>>

Quoted 4 lines · Ian Campbell

On Wed, 2012-02-22 at 19:17 +0000, Attilio Rao wrote:
Can you confirm that you need an OVMF which matches the OS bit-width you are installing. i..e that there is no support for booting a 32 bit EFI OS (or bootloader, shell, whatever it is called) on a 64 bit OVMF?

I didn't test this case, really, but I would think OVMF-64 / OS-32 could possibly work.

Native EFI requires bit-matched OS loaders,

Quoted 7 lines · Jan Beulich

Quoted 7 lines

Quoted 1 line

Quoted 1 line

Attilio Rao <[email protected]> 02/23/12 11:18 AM >>>

Quoted 4 lines · Ian Campbell

On Wed, 2012-02-22 at 19:17 +0000, Attilio Rao wrote:
Can you confirm that you need an OVMF which matches the OS bit-width you are installing. i..e that there is no support for booting a 32 bit EFI OS (or bootloader, shell, whatever it is called) on a 64 bit OVMF?

Quoted 4 lines

Quoted 2 lines

I didn't test this case, really, but I would think OVMF-64 / OS-32 could possibly work.

Native EFI requires bit-matched OS loaders,

Is that a shortcoming of EFI generally or just this implementation?

Surely people don't reflash their "BIOS" to be able to run a 32 vs 64 bit OS? Or do most OSes (even 32 bit ones) have a 64 bit loader capable of loading a 32 bit OS?

Quoted 11 lines · Ian Campbell

Quoted 10 lines · Jan Beulich

Quoted 9 lines

Quoted 1 line

Quoted 1 line

Attilio Rao <[email protected]> 02/23/12 11:18 AM >>>

Quoted 4 lines · Ian Campbell

On Wed, 2012-02-22 at 19:17 +0000, Attilio Rao wrote:
Can you confirm that you need an OVMF which matches the OS bit-width you are installing. i..e that there is no support for booting a 32 bit EFI OS (or bootloader, shell, whatever it is called) on a 64 bit OVMF?

I didn't test this case, really, but I would think OVMF-64 / OS-32 could possibly work.

Quoted 3 lines

Quoted 1 line

Native EFI requires bit-matched OS loaders,

Is that a shortcoming of EFI generally or just this implementation?

This is basically built into the design of UEFI. The issue is that the firmware boot/runtime calls are only available for the native architecture.

If the OS or loader had support for changing to the native architecture before calling these services, it can run in another mode.

Quoted 3 lines

Surely people don't reflash their "BIOS" to be able to run a 32 vs 64 bit OS? Or do most OSes (even 32 bit ones) have a 64 bit loader capable of loading a 32 bit OS?

I don't think people often update their firmware to switch modes. In fact, I think in most cases they don't have that option. For example, most desktop/server systems with UEFI support will likely only support UEFI X64.

The loader or OS could have special support for running under this environment. It would just need to change to the proper CPU mode before calling the firmware runtime services.

In the case of UEFI Linux and Windows x86, I think they only support calling UEFI IA32. In the case of UEFI Linux and Windows x86-64, I think they only support calling UEFI X64.

Quoted 1 line

Quoted 1 line · Ian Campbell

Quoted 7 lines · Jan Beulich

Quoted 7 lines

Quoted 1 line

Quoted 1 line

Attilio Rao <[email protected]> 02/23/12 11:18 AM >>>

Quoted 4 lines · Ian Campbell

On Wed, 2012-02-22 at 19:17 +0000, Attilio Rao wrote:
Can you confirm that you need an OVMF which matches the OS bit-width you are installing. i..e that there is no support for booting a 32 bit EFI OS (or bootloader, shell, whatever it is called) on a 64 bit OVMF?

Quoted 4 lines

Quoted 2 lines

I didn't test this case, really, but I would think OVMF-64 / OS-32 could possibly work.

Native EFI requires bit-matched OS loaders,

Is that a shortcoming of EFI generally or just this implementation?

Surely people don't reflash their "BIOS" to be able to run a 32 vs 64 bit OS? Or do most OSes (even 32 bit ones) have a 64 bit loader capable of loading a 32 bit OS?

Quoted 9 lines

Quoted 1 line

Quoted 1 line · Ian Campbell

Quoted 7 lines · Jan Beulich

Quoted 7 lines

Quoted 1 line

Quoted 1 line

Attilio Rao <[email protected]> 02/23/12 11:18 AM >>>

Quoted 4 lines · Ian Campbell

On Wed, 2012-02-22 at 19:17 +0000, Attilio Rao wrote:
Can you confirm that you need an OVMF which matches the OS bit-width you are installing. i..e that there is no support for booting a 32 bit EFI OS (or bootloader, shell, whatever it is called) on a 64 bit OVMF?

Quoted 6 lines

Quoted 4 lines

Quoted 2 lines

I didn't test this case, really, but I would think OVMF-64 / OS-32 could possibly work.

Native EFI requires bit-matched OS loaders,

Is that a shortcoming of EFI generally or just this implementation?

I'd assume more the former.

Quoted 3 lines

Surely people don't reflash their "BIOS" to be able to run a 32 vs 64 bit OS? Or do most OSes (even 32 bit ones) have a 64 bit loader capable of loading a 32 bit OS?

When I asked the same question, I was told that the assumption is that on modern (read: UEFI) systems people aren't expected to run 32-bit OSes.

And no, I don't think any 32-bit OS comes with a 64-bit bootloader. Furthermore, to make EFI really work, such an OS would also need 64-bit stubs to call the EFI services - not something that's realistically going to happen I would think.

If anything, I would have expected that things could work out the other way around: A 64-bit OS having a 32-bit loader and 32-bit stubs (which is how we implemented this when, on x86, there was no 64-bit EFI yet).

Quoted 1 line

Quoted 1 line · Ian Campbell

Quoted 22 lines · Jan Beulich

Quoted 9 lines

Quoted 1 line

Quoted 1 line · Ian Campbell

Quoted 7 lines · Jan Beulich

Quoted 7 lines

Quoted 1 line

Quoted 1 line

Attilio Rao <[email protected]> 02/23/12 11:18 AM >>>

Quoted 4 lines · Ian Campbell

On Wed, 2012-02-22 at 19:17 +0000, Attilio Rao wrote:
Can you confirm that you need an OVMF which matches the OS bit-width you are installing. i..e that there is no support for booting a 32 bit EFI OS (or bootloader, shell, whatever it is called) on a 64 bit OVMF?

Quoted 6 lines

Quoted 4 lines

Quoted 2 lines

I didn't test this case, really, but I would think OVMF-64 / OS-32 could possibly work.

Native EFI requires bit-matched OS loaders,

Is that a shortcoming of EFI generally or just this implementation?

I'd assume more the former.

Quoted 3 lines

Surely people don't reflash their "BIOS" to be able to run a 32 vs 64 bit OS? Or do most OSes (even 32 bit ones) have a 64 bit loader capable of loading a 32 bit OS?

Quoted 3 lines

When I asked the same question, I was told that the assumption is that on modern (read: UEFI) systems people aren't expected to run 32-bit OSes.

Doesn't that apply to running those OSes under Xen to some extent as well? Can we get away with only supporting 64 bit EFI?

Quoted 9 lines

And no, I don't think any 32-bit OS comes with a 64-bit bootloader. Furthermore, to make EFI really work, such an OS would also need 64-bit stubs to call the EFI services - not something that's realistically going to happen I would think.

If anything, I would have expected that things could work out the other way around: A 64-bit OS having a 32-bit loader and 32-bit stubs (which is how we implemented this when, on x86, there was no 64-bit EFI yet).

Yes, that does sound more plausible. Does anyone still do that though?

What about in a situation where they could just as easily run a traditional BIOS (like in a Xen HVM guest)? Why would anyone insist on being able to use 32 bit EFI if they could just use SeaBIOS? I suppose the underlying question is: are there any OSes which _only_ support 32 bit EFI and don't support a traditional BIOS?

Quoted 2 lines · Attilio Rao

A way to integrate OVMF build directly into XEN has still be discussed on the mailing list appropriately.

AIUI OVMF is maintained in SVN. Our normal procedure for adding an external dependency would be for us to mirror it on xenbits as a convenience to our users, who don't need to get stuff from multiple places, and as a courtesy to our upstreams, so our users don't consume their resources.

I don't much fancy setting the necessary webdav or whatever stuff on xenbits and integrating SVN support into our build system though. What do people think about using git-svn to manage our mirror in git instead? Or better: perhaps OVMF have an official git or hg mirror?

Quoted 10 lines · Ian Campbell

Quoted 2 lines · Attilio Rao

A way to integrate OVMF build directly into XEN has still be discussed on the mailing list appropriately.

AIUI OVMF is maintained in SVN. Our normal procedure for adding an external dependency would be for us to mirror it on xenbits as a convenience to our users, who don't need to get stuff from multiple places, and as a courtesy to our upstreams, so our users don't consume their resources.

Quoted 4 lines

I don't much fancy setting the necessary webdav or whatever stuff on xenbits and integrating SVN support into our build system though. What do people think about using git-svn to manage our mirror in git instead? Or better: perhaps OVMF have an official git or hg mirror?

These are not 100% official, but I have been mirroring to git for over a year now:
http://sourceforge.net/apps/mediawiki/tianocore/index.php?title=Source_Control#Mirrors

-Jordan

when specified in the guest configuration file.
This work is somewhat based on Bei Guan effort during the SoC 2011 and relies on upstream edk2/ovmf Tianocore ROM to be built separately and manually copied as:
Build/OvmfX64/DEBUG_GCC44/FV/OVMF.fd -> tools/firmware/ovmf/ovmf-x64.bin Build/OvmfIa32/DEBUG_GCC44/FV/OVMF.fd -> toolf/firmware/ovmf/ovmf-ia32.bin

A way to integrate OVMF build directly into XEN has still be discussed on the mailing list appropriately.

Signed-off-by Attilio Rao <[email protected]>

diff -r a88ba599add1 -r 032fea10f8d1 Config.mk

Config.mk Wed Feb 22 18:54:03 2012 +0000 renamed from Config.mk Tue Feb 21 17:45:59 2012 +0000 +1 -0

@@ -224,6 +224,7 @@ SEABIOS_UPSTREAM_TAG ?= rel-1.6.3.1
 
 ETHERBOOT_NICS ?= rtl8139 8086100e
 
+CONFIG_OVMF ?= y
 CONFIG_ROMBIOS ?= y
 CONFIG_SEABIOS ?= y
 

diff -r a88ba599add1 -r 032fea10f8d1 tools/firmware/hvmloader/Makefile

tools/firmware/hvmloader/Makefile Wed Feb 22 18:54:03 2012 +0000 renamed from tools/firmware/hvmloader/Makefile Tue Feb 21 17:45:59 2012 +0000 +9 -0

@@ -37,6 +37,7 @@ endif
 
 CIRRUSVGA_DEBUG ?= n
 
+OVMF_DIR := ../ovmf
 ROMBIOS_DIR := ../rombios
 SEABIOS_DIR := ../seabios-dir
 

@@ -52,6 +53,14 @@ endif
 
 ROMS := 
 
+ifeq ($(CONFIG_OVMF),y)
+OBJS += ovmf.o
+CFLAGS += -DENABLE_OVMF32 -DENABLE_OVMF64
+OVMF32_ROM := $(OVMF_DIR)/ovmf-ia32.bin
+OVMF64_ROM := $(OVMF_DIR)/ovmf-x64.bin
+ROMS += $(OVMF32_ROM) $(OVMF64_ROM)
+endif
+
 ifeq ($(CONFIG_ROMBIOS),y)
 OBJS += optionroms.o 32bitbios_support.o rombios.o
 CFLAGS += -DENABLE_ROMBIOS

@@ -70,7 +79,7 @@ endif
 all: subdirs-all

$(MAKE) hvmloader

tools/firmware/hvmloader/Makefile Wed Feb 22 18:54:03 2012 +0000 renamed from tools/firmware/hvmloader/Makefile Tue Feb 21 17:45:59 2012 +0000 +1 -1

-rombios.o seabios.o hvmloader.o: roms.inc
+ovmf.o rombios.o seabios.o hvmloader.o: roms.inc
 smbios.o: CFLAGS += -D__SMBIOS_DATE__="\"$(shell date +%m/%d/%Y)\""
 
 hvmloader: $(OBJS) acpi/acpi.a

@@ -93,6 +102,18 @@ ifneq ($(SEABIOS_ROM),)

echo "#endif" >> [email protected]
endif

tools/firmware/hvmloader/Makefile Wed Feb 22 18:54:03 2012 +0000 renamed from tools/firmware/hvmloader/Makefile Tue Feb 21 17:45:59 2012 +0000 +12 -0

+ifneq ($(OVMF32_ROM),)
+ echo "#ifdef ROM_INCLUDE_OVMF32" >> [email protected]
+ sh ./mkhex ovmf32 $(OVMF32_ROM) >> [email protected]
+ echo "#endif" >> [email protected] 
+endif 
+
+ifneq ($(OVMF64_ROM),)
+ echo "#ifdef ROM_INCLUDE_OVMF64" >> [email protected]
+ sh ./mkhex ovmf64 $(OVMF64_ROM) >> [email protected]
+ echo "#endif" >> [email protected] 
+endif 
+
 ifneq ($(STDVGA_ROM),)

echo "#ifdef ROM_INCLUDE_VGABIOS" >> [email protected]
sh ./mkhex vgabios_stdvga $(STDVGA_ROM) >> [email protected]
diff -r a88ba599add1 -r 032fea10f8d1 tools/firmware/hvmloader/config.h

tools/firmware/hvmloader/config.h Wed Feb 22 18:54:03 2012 +0000 renamed from tools/firmware/hvmloader/config.h Tue Feb 21 17:45:59 2012 +0000 +2 -0

@@ -35,6 +35,8 @@ struct bios_config {
 
 extern struct bios_config rombios_config;
 extern struct bios_config seabios_config;
+extern struct bios_config ovmf32_config;
+extern struct bios_config ovmf64_config;
 
 #define PAGE_SHIFT 12
 #define PAGE_SIZE  (1ul << PAGE_SHIFT)

diff -r a88ba599add1 -r 032fea10f8d1 tools/firmware/hvmloader/hvmloader.c

tools/firmware/hvmloader/hvmloader.c Wed Feb 22 18:54:03 2012 +0000 renamed from tools/firmware/hvmloader/hvmloader.c Tue Feb 21 17:45:59 2012 +0000 +6 -0

@@ -212,6 +212,12 @@ struct bios_info {
 #ifdef ENABLE_SEABIOS
     { "seabios", &seabios_config, },
 #endif
+#ifdef ENABLE_OVMF32
+    { "ovmf-ia32", &ovmf32_config, },
+#endif
+#ifdef ENABLE_OVMF64
+    { "ovmf-x64", &ovmf64_config, },
+#endif
     { NULL, NULL }
 };
 

diff -r a88ba599add1 -r 032fea10f8d1 tools/firmware/hvmloader/ovmf.c

tools/firmware/hvmloader/ovmf.c Wed Feb 22 18:54:03 2012 +0000 renamed from dev/null Thu Jan 01 00:00:00 1970 +0000 +20 -0

@@ -0,0 +1,147 @@
+/*
+ * HVM OVMF UEFI support.
+ *
+ * Bei Guan, [email protected]
+ * Andrei Warkentin, [email protected]
+ * Leendert van Doorn, [email protected]
+ * Copyright (c) 2005, International Business Machines Corporation.
+ * Copyright (c) 2006, Keir Fraser, XenSource Inc.
+ * Copyright (c) 2011, Citrix Inc.
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms and conditions of the GNU General Public License,
+ * version 2, as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for
+ * more details.
+ *
+ * You should have received a copy of the GNU General Public License along

with
+ * this program; if not, write to the Free Software Foundation, Inc., 59 Temple
+ * Place - Suite 330, Boston, MA 02111-1307 USA.
+ */

tools/firmware/hvmloader/ovmf.c Wed Feb 22 18:54:03 2012 +0000 renamed from dev/null Thu Jan 01 00:00:00 1970 +0000 +68 -0

+
+#include "config.h"
+#include "smbios_types.h"
+#include "acpi/acpi2_0.h"
+#include "apic_regs.h"
+#include "../rombios/config.h"
+#include "util.h"
+#include "pci_regs.h"
+#include "hypercall.h"
+
+#include <xen/hvm/params.h>
+#include <xen/hvm/ioreq.h>
+#include <xen/memory.h>
+
+#define ROM_INCLUDE_OVMF32
+#define ROM_INCLUDE_OVMF64
+#include "roms.inc"
+
+#define OVMF_BEGIN              0xFFF00000ULL
+#define OVMF_SIZE               0x00100000ULL
+#define OVMF_MAXOFFSET          0x000FFFFFULL
+#define OVMF_END                (OVMF_BEGIN + OVMF_SIZE)
+#define LOWCHUNK_BEGIN          0x000F0000
+#define LOWCHUNK_SIZE           0x00010000
+#define LOWCHUNK_MAXOFFSET      0x0000FFFF
+#define LOWCHUNK_END            (OVMF_BEGIN + OVMF_SIZE)
+
+extern unsigned char dsdt_anycpu[], dsdt_15cpu[];
+extern int dsdt_anycpu_len, dsdt_15cpu_len;
+
+static void ovmf_load(const struct bios_config *config)
+{
+    xen_pfn_t mfn;
+    uint64_t addr = OVMF_BEGIN;
+
+    /* Copy low-reset vector portion. */
+    memcpy((void *) LOWCHUNK_BEGIN, (uint8_t *) config->image
+           + OVMF_SIZE
+           - LOWCHUNK_SIZE,
+           LOWCHUNK_SIZE);
+
+    /* Ensure we have backing page prior to moving FD. */
+    while ((addr >> PAGE_SHIFT) != (OVMF_END >> PAGE_SHIFT)) {
+        mfn = (uint32_t) (addr >> PAGE_SHIFT);
+        addr += PAGE_SIZE;
+ mem_hole_populate_ram(mfn, 1);
+    }
+
+    /* Copy FD. */
+    memcpy((void *) OVMF_BEGIN, config->image, OVMF_SIZE);
+}
+
+static void ovmf_acpi_build_tables(void)
+{
+    struct acpi_config config = {
+        .dsdt_anycpu = dsdt_anycpu,
+        .dsdt_anycpu_len = dsdt_anycpu_len,
+        .dsdt_15cpu = dsdt_15cpu,
+        .dsdt_15cpu_len = dsdt_15cpu_len,
+    };
+
+    acpi_build_tables(&config, ACPI_PHYSICAL_ADDRESS);
+}
+
+static void ovmf_create_smbios_tables(void)
+{
+    hvm_write_smbios_tables(SMBIOS_PHYSICAL_ADDRESS,
+                            SMBIOS_PHYSICAL_ADDRESS + sizeof(struct

smbios_entry_point),

tools/firmware/hvmloader/ovmf.c Wed Feb 22 18:54:03 2012 +0000 renamed from dev/null Thu Jan 01 00:00:00 1970 +0000 +56 -0

+                            SMBIOS_PHYSICAL_END);
+}
+
+struct bios_config ovmf32_config =  {
+    .name = "OVMF-IA32",
+
+    .image = ovmf32,
+    .image_size = sizeof(ovmf32),
+
+    .bios_address = 0,
+    .bios_load = ovmf_load,
+
+    .load_roms = 0,
+
+    .bios_info_setup = NULL,
+    .bios_info_finish = NULL,
+
+    .e820_setup = NULL,
+
+    .acpi_build_tables = ovmf_acpi_build_tables,
+    .create_mp_tables = NULL,
+    .create_smbios_tables = ovmf_create_smbios_tables,
+    .create_pir_tables = NULL,
+};
+
+struct bios_config ovmf64_config =  {
+    .name = "OVMF-X64",
+
+    .image = ovmf64,
+    .image_size = sizeof(ovmf64),
+
+    .bios_address = 0,
+    .bios_load = ovmf_load,
+
+    .load_roms = 0,
+
+    .bios_info_setup = NULL,
+    .bios_info_finish = NULL,
+
+    .e820_setup = NULL,
+
+    .acpi_build_tables = ovmf_acpi_build_tables,
+    .create_mp_tables = NULL,
+    .create_smbios_tables = ovmf_create_smbios_tables,
+    .create_pir_tables = NULL,
+};
+
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * tab-width: 4
+ * indent-tabs-mode: nil
+ * End:
+ */

_______________________________________________
Xen-devel mailing list
[email protected]
http://lists.xen.org/xen-devel

configuration file.
An example is given by:
bios_override="ovmf-x64"

tools/libxl/libxl_types.idl +0 -0

                                        ("pae", bool),
                                        ("apic", bool),
                                        ("acpi", bool),

diff -r 032fea10f8d1 -r 520ba1527b7a tools/libxl/xl_cmdimpl.c

tools/libxl/xl_cmdimpl.c +2 -0

@@ -704,6 +704,8 @@ static void parse_config_data(const char
 
         xlu_cfg_replace_string (config, "firmware_override",
                                 &b_info->u.hvm.firmware, 0);
+        xlu_cfg_replace_string (config, "bios_override",
+                                &b_info->u.hvm.bios, 0);
         if (!xlu_cfg_get_long (config, "pae", &l, 0))
             b_info->u.hvm.pae = l;
         if (!xlu_cfg_get_long (config, "apic", &l, 0))

_______________________________________________
Xen-devel mailing list
[email protected]
http://lists.xen.org/xen-devel

Quoted 4 lines · Attilio Rao

configuration file.
An example is given by:
bios_override="ovmf-x64"

I'm not sure I would use the override suffix here -- that is generally for settings where we recommend that the user accepts the default. In this case though a user has perfectly valid reasons for selecting ovmf-{32,64} or seabios etc.

Also please update docs/man/xl.cfg.pod.5 to document the new setting.

Quoted 7 lines

diff -r 032fea10f8d1 -r 520ba1527b7a tools/libxl/libxl_dm.c

tools/libxl/libxl_dm.c +0 -0

@@ -66,6 +66,8 @@ const char *libxl__domain_device_model(l
  static const char *libxl__domain_bios(libxl__gc *gc,
                                  const libxl_domain_build_info *info)
  {

tools/libxl/libxl_dm.c const char *libxl__domain_device_model(l · line 73

Quoted 6 lines

tools/libxl/libxl_dm.c +2 -0

+    if (info->u.hvm.bios)
+       return info->u.hvm.bios;
      switch (info->device_model_version) {
      case 1: return "rombios";
      case 2: return "seabios";

Should integrate this function into libxl__domain_build_info_setdefaults from my "libxl: improved handling for default values in API" series.

Also it would be good to use that same infrastructure to enforce that qemu-xen-traditional can only use rombios and that seabios and ovmf-* are only valid with qemu-xen.

Quoted 5 lines

diff -r 032fea10f8d1 -r 520ba1527b7a tools/libxl/libxl_types.idl

tools/libxl/libxl_types.idl +0 -0

@@ -228,6 +228,7 @@ libxl_domain_build_info = Struct("domain
 

tools/libxl/libxl_types.idl libxl_domain_build_info = Struct("domain

Quoted 4 lines

tools/libxl/libxl_types.idl +1 -0

      ("u", KeyedUnion(None, libxl_domain_type, "type",
                  [("hvm", Struct(None, [("firmware", string),
+                                       ("bios", string),
 

I think an Enumeration would be better here.
libxl__domain_bios

Quoted 6 lines · Ian Campbell

Quoted 4 lines · Attilio Rao

configuration file.
An example is given by:
bios_override="ovmf-x64"

Quoted 7 lines

I'm not sure I would use the override suffix here -- that is generally for settings where we recommend that the user accepts the default. In this case though a user has perfectly valid reasons for selecting ovmf-{32,64} or seabios etc.

Also please update docs/man/xl.cfg.pod.5 to document the new setting.

It makes sense, thanks.

Quoted 7 lines

Quoted 7 lines

diff -r 032fea10f8d1 -r 520ba1527b7a tools/libxl/libxl_dm.c

tools/libxl/libxl_dm.c +0 -0

@@ -66,6 +66,8 @@ const char *libxl__domain_device_model(l
  static const char *libxl__domain_bios(libxl__gc *gc,
                                  const libxl_domain_build_info *info)
  {

Quoted 10 lines

tools/libxl/libxl_dm.c const char *libxl__domain_device_model(l · line 73

Quoted 6 lines

tools/libxl/libxl_dm.c +2 -0

+    if (info->u.hvm.bios)
+       return info->u.hvm.bios;
      switch (info->device_model_version) {
      case 1: return "rombios";
      case 2: return "seabios";

Should integrate this function into libxl__domain_build_info_setdefaults from my "libxl: improved handling for default values in API" series.

I really wanted to do this type of integration in a separate step.

Quoted 10 lines

Also it would be good to use that same infrastructure to enforce that qemu-xen-traditional can only use rombios and that seabios and ovmf-* are only valid with qemu-xen.

Quoted 5 lines

diff -r 032fea10f8d1 -r 520ba1527b7a tools/libxl/libxl_types.idl

tools/libxl/libxl_types.idl +0 -0

@@ -228,6 +228,7 @@ libxl_domain_build_info = Struct("domain
 

Quoted 6 lines

tools/libxl/libxl_types.idl libxl_domain_build_info = Struct("domain

Quoted 4 lines

tools/libxl/libxl_types.idl +1 -0

      ("u", KeyedUnion(None, libxl_domain_type, "type",
                  [("hvm", Struct(None, [("firmware", string),
+                                       ("bios", string),
 

I think an Enumeration would be better here.
libxl__domain_bios

I just found it quicker/cleaner to just store the string and pass it down, rather than translating to an Enumeration and then translate it back to a string into libxl__domain_bios(), don't you think?

However I'm open to do what you feel is better.

Thanks,
Attilio