June 2016 - SeaBIOS - mail.coreboot.org

[PATCH v3] fw/msr_feature_control: add support to set MSR_IA32_FEATURE_CONTROL
by Haozhong Zhang July 7, 2016

July 7, 2016

OS usually expects BIOS to set certain bits in MSR_IA32_FEATURE_CONTROL for some features (e.g. VMX and LMCE). QEMU provides a fw_cfg file "etc/msr_feature_control" to advise bits that should be set in MSR_IA32_FEATURE_CONTROL. If this file exists, SeaBIOS will set the advised bits in that MSR. Signed-off-by: Haozhong Zhang <haozhong.zhang(a)intel.com> Reviewed-by: Paolo Bonzini <pbonzini(a)redhat.com> --- Changes in v3: * Move msr_feature_control_setup() to paravirt.c. Changes in v2: * Call msr_feature_control_setup() before smp_setup(). * Use wrmsr_smp() instead of wrmsr() on BSP. * Rename smp_mtrr and smp_mtrr_count to smp_msr and smp_msr_count as they are not only used for MTRR now. --- src/fw/paravirt.c | 12 +++++++++++- src/fw/smp.c | 20 ++++++++++---------- 2 files changed, 21 insertions(+), 11 deletions(-) diff --git a/src/fw/paravirt.c b/src/fw/paravirt.c index 8ed4380..73a08f0 100644 --- a/src/fw/paravirt.c +++ b/src/fw/paravirt.c @@ -131,6 +131,15 @@ qemu_preinit(void) dprintf(1, "RamSize: 0x%08x [cmos]\n", RamSize); } +#define MSR_IA32_FEATURE_CONTROL 0x0000003a + +static void msr_feature_control_setup(void) +{ + u64 feature_control_bits = romfile_loadint("etc/msr_feature_control", 0); + if (feature_control_bits) + wrmsr_smp(MSR_IA32_FEATURE_CONTROL, feature_control_bits); +} + void qemu_platform_setup(void) { @@ -149,8 +158,9 @@ qemu_platform_setup(void) smm_device_setup(); smm_setup(); - // Initialize mtrr and smp + // Initialize mtrr, msr_feature_control and smp mtrr_setup(); + msr_feature_control_setup(); smp_setup(); // Create bios tables diff --git a/src/fw/smp.c b/src/fw/smp.c index 579acdb..6e706e4 100644 --- a/src/fw/smp.c +++ b/src/fw/smp.c @@ -10,7 +10,7 @@ #include "output.h" // dprintf #include "romfile.h" // romfile_loadint #include "stacks.h" // yield -#include "util.h" // smp_setup +#include "util.h" // smp_setup, msr_feature_control_setup #include "x86.h" // wrmsr #define APIC_ICR_LOW ((u8*)BUILD_APIC_ADDR + 0x300) @@ -20,20 +20,20 @@ #define APIC_ENABLED 0x0100 -static struct { u32 index; u64 val; } smp_mtrr[32]; -static u32 smp_mtrr_count; +static struct { u32 index; u64 val; } smp_msr[32]; +static u32 smp_msr_count; void wrmsr_smp(u32 index, u64 val) { wrmsr(index, val); - if (smp_mtrr_count >= ARRAY_SIZE(smp_mtrr)) { + if (smp_msr_count >= ARRAY_SIZE(smp_msr)) { warn_noalloc(); return; } - smp_mtrr[smp_mtrr_count].index = index; - smp_mtrr[smp_mtrr_count].val = val; - smp_mtrr_count++; + smp_msr[smp_msr_count].index = index; + smp_msr[smp_msr_count].val = val; + smp_msr_count++; } u32 MaxCountCPUs; @@ -58,10 +58,10 @@ handle_smp(void) u8 apic_id = ebx>>24; dprintf(DEBUG_HDL_smp, "handle_smp: apic_id=%d\n", apic_id); - // MTRR setup + // MTRR and MSR_IA32_FEATURE_CONTROL setup int i; - for (i=0; i<smp_mtrr_count; i++) - wrmsr(smp_mtrr[i].index, smp_mtrr[i].val); + for (i=0; i<smp_msr_count; i++) + wrmsr(smp_msr[i].index, smp_msr[i].val); // Set bit on FoundAPICIDs FoundAPICIDs[apic_id/32] |= (1 << (apic_id % 32)); -- 2.9.0

4 21

[PATCH v2 0/4] support booting more than 255 CPUs with QEMU
by Igor Mammedov June 27, 2016

June 27, 2016

Changelog since: v1: * s/count_cpu/apic_id_init/ * merge handle_x2apic() into apic_id_init() RFC: * move out max-cpus check out of mptable_setup() * factor out CPU counting/apic ID detection in separate function * return back accidentially deleted debug message with APIC ID * drop unused code in smp_setup() According to SDM, if CPUs have APIC ID more than 254 firmware should pass control to OS in x2APIC mode. This series adds x2APIC bootstrap initialization. QEMU side of x2APIC support: https://lists.gnu.org/archive/html/qemu-devel/2016-05/msg01094.html Igor Mammedov (3): paravirt: disable legacy bios tables in case of more than 255 CPUs support booting with more than 255 CPUs cleanup smp_setup() Kevin O'Connor (1): smp: refactor present CPU APIC ID detection and counting src/fw/paravirt.c | 6 ++++-- src/fw/smp.c | 57 ++++++++++++++++++++++++++++++++++++------------------- src/x86.h | 1 + 3 files changed, 42 insertions(+), 22 deletions(-) -- 1.8.3.1

5 15

[PATCH 0/2] virtio: pci cfg access
by Gerd Hoffmann June 20, 2016

June 20, 2016

Hi, I'm sure I had sent this before, but appearently totally forgot about it. Just tested booting with virtio bars mapped above 4G, didn't work. Investigated, found this bitroting in a local branch. Undusted it, rebased to latest master with some fixups, and here it is ... Gerd Hoffmann (2): virtio: uninline _vp_{read,write} virtio: pci cfg access src/hw/virtio-pci.c | 254 ++++++++++++++++++++++++++++++++++++++++++++++++---- src/hw/virtio-pci.h | 94 ++++--------------- 2 files changed, 252 insertions(+), 96 deletions(-) -- 1.8.3.1

2 4

[PATCH v2] fw/msr_feature_control: add support to set MSR_IA32_FEATURE_CONTROL
by Haozhong Zhang June 19, 2016

June 19, 2016

OS usually expects BIOS to set certain bits in MSR_IA32_FEATURE_CONTROL for some features (e.g. VMX and LMCE). QEMU provides a fw_cfg file "etc/msr_feature_control" to advise bits that should be set in MSR_IA32_FEATURE_CONTROL. If this file exists, SeaBIOS will set the advised bits in that MSR. Signed-off-by: Haozhong Zhang <haozhong.zhang(a)intel.com> --- Changes in v2: * Call msr_feature_control_setup() before smp_setup(). * Use wrmsr_smp() instead of wrmsr() on BSP. * Rename smp_mtrr and smp_mtrr_count to smp_msr and smp_msr_count as they are not only used for MTRR now. --- Makefile | 2 +- src/fw/msr_feature_control.c | 16 ++++++++++++++++ src/fw/paravirt.c | 3 ++- src/fw/smp.c | 20 ++++++++++---------- src/util.h | 3 +++ 5 files changed, 32 insertions(+), 12 deletions(-) create mode 100644 src/fw/msr_feature_control.c diff --git a/Makefile b/Makefile index 4930b3a..f38a075 100644 --- a/Makefile +++ b/Makefile @@ -43,7 +43,7 @@ SRC32FLAT=$(SRCBOTH) post.c e820map.c malloc.c romfile.c x86.c optionroms.c \ fw/paravirt.c fw/shadow.c fw/pciinit.c fw/smm.c fw/smp.c fw/mtrr.c fw/xen.c \ fw/acpi.c fw/mptable.c fw/pirtable.c fw/smbios.c fw/romfile_loader.c \ hw/virtio-ring.c hw/virtio-pci.c hw/virtio-blk.c hw/virtio-scsi.c \ - hw/tpm_drivers.c + hw/tpm_drivers.c fw/msr_feature_control.c SRC32SEG=string.c output.c pcibios.c apm.c stacks.c hw/pci.c hw/serialio.c DIRS=src src/hw src/fw vgasrc diff --git a/src/fw/msr_feature_control.c b/src/fw/msr_feature_control.c new file mode 100644 index 0000000..5ddc051 --- /dev/null +++ b/src/fw/msr_feature_control.c @@ -0,0 +1,16 @@ +#include "util.h" // msr_feature_control_setup, wrmsr_smp +#include "romfile.h" // romfile_find + +#define MSR_IA32_FEATURE_CONTROL 0x0000003a + +void msr_feature_control_setup(void) +{ + struct romfile_s *f = romfile_find("etc/msr_feature_control"); + if (!f) + return; + + u64 feature_control_bits; + f->copy(f, &feature_control_bits, sizeof(feature_control_bits)); + if (feature_control_bits) + wrmsr_smp(MSR_IA32_FEATURE_CONTROL, feature_control_bits); +} diff --git a/src/fw/paravirt.c b/src/fw/paravirt.c index 8ed4380..dbb3406 100644 --- a/src/fw/paravirt.c +++ b/src/fw/paravirt.c @@ -149,8 +149,9 @@ qemu_platform_setup(void) smm_device_setup(); smm_setup(); - // Initialize mtrr and smp + // Initialize mtrr, msr_feature_control and smp mtrr_setup(); + msr_feature_control_setup(); smp_setup(); // Create bios tables diff --git a/src/fw/smp.c b/src/fw/smp.c index 579acdb..6e706e4 100644 --- a/src/fw/smp.c +++ b/src/fw/smp.c @@ -10,7 +10,7 @@ #include "output.h" // dprintf #include "romfile.h" // romfile_loadint #include "stacks.h" // yield -#include "util.h" // smp_setup +#include "util.h" // smp_setup, msr_feature_control_setup #include "x86.h" // wrmsr #define APIC_ICR_LOW ((u8*)BUILD_APIC_ADDR + 0x300) @@ -20,20 +20,20 @@ #define APIC_ENABLED 0x0100 -static struct { u32 index; u64 val; } smp_mtrr[32]; -static u32 smp_mtrr_count; +static struct { u32 index; u64 val; } smp_msr[32]; +static u32 smp_msr_count; void wrmsr_smp(u32 index, u64 val) { wrmsr(index, val); - if (smp_mtrr_count >= ARRAY_SIZE(smp_mtrr)) { + if (smp_msr_count >= ARRAY_SIZE(smp_msr)) { warn_noalloc(); return; } - smp_mtrr[smp_mtrr_count].index = index; - smp_mtrr[smp_mtrr_count].val = val; - smp_mtrr_count++; + smp_msr[smp_msr_count].index = index; + smp_msr[smp_msr_count].val = val; + smp_msr_count++; } u32 MaxCountCPUs; @@ -58,10 +58,10 @@ handle_smp(void) u8 apic_id = ebx>>24; dprintf(DEBUG_HDL_smp, "handle_smp: apic_id=%d\n", apic_id); - // MTRR setup + // MTRR and MSR_IA32_FEATURE_CONTROL setup int i; - for (i=0; i<smp_mtrr_count; i++) - wrmsr(smp_mtrr[i].index, smp_mtrr[i].val); + for (i=0; i<smp_msr_count; i++) + wrmsr(smp_msr[i].index, smp_msr[i].val); // Set bit on FoundAPICIDs FoundAPICIDs[apic_id/32] |= (1 << (apic_id % 32)); diff --git a/src/util.h b/src/util.h index 7b41207..61877fa 100644 --- a/src/util.h +++ b/src/util.h @@ -103,6 +103,9 @@ int csm_bootprio_pci(struct pci_device *pci); // fw/mptable.c void mptable_setup(void); +// fw/msr_feature_control.c +void msr_feature_control_setup(void); + // fw/mtrr.c void mtrr_setup(void); -- 2.9.0

3 3

[PATCH] fw/msr_feature_control: add support to set MSR_IA32_FEATURE_CONTROL
by Haozhong Zhang June 16, 2016

June 16, 2016

OS usually expects BIOS to set certain bits in MSR_IA32_FEATURE_CONTROL for some features (e.g. VMX and LMCE). QEMU provides a fw_cfg file "etc/msr_feature_control" to advise bits that should be set in MSR_IA32_FEATURE_CONTROL. If this file exists, SeaBIOS will set the advised bits in that MSR. Signed-off-by: Haozhong Zhang <haozhong.zhang(a)intel.com> --- QEMU patch added fw_cfg file etc/msr_feature_control can be found at [1]. Note I mistakenly used u32 as the type of file content in that patch, which should be u64 and will be fixed. [1] https://lists.nongnu.org/archive/html/qemu-devel/2016-06/msg04389.html --- Makefile | 2 +- src/fw/msr_feature_control.c | 16 ++++++++++++++++ src/fw/paravirt.c | 3 +++ src/fw/smp.c | 6 +++++- src/util.h | 5 +++++ 5 files changed, 30 insertions(+), 2 deletions(-) create mode 100644 src/fw/msr_feature_control.c diff --git a/Makefile b/Makefile index 4930b3a..f38a075 100644 --- a/Makefile +++ b/Makefile @@ -43,7 +43,7 @@ SRC32FLAT=$(SRCBOTH) post.c e820map.c malloc.c romfile.c x86.c optionroms.c \ fw/paravirt.c fw/shadow.c fw/pciinit.c fw/smm.c fw/smp.c fw/mtrr.c fw/xen.c \ fw/acpi.c fw/mptable.c fw/pirtable.c fw/smbios.c fw/romfile_loader.c \ hw/virtio-ring.c hw/virtio-pci.c hw/virtio-blk.c hw/virtio-scsi.c \ - hw/tpm_drivers.c + hw/tpm_drivers.c fw/msr_feature_control.c SRC32SEG=string.c output.c pcibios.c apm.c stacks.c hw/pci.c hw/serialio.c DIRS=src src/hw src/fw vgasrc diff --git a/src/fw/msr_feature_control.c b/src/fw/msr_feature_control.c new file mode 100644 index 0000000..35d4ab8 --- /dev/null +++ b/src/fw/msr_feature_control.c @@ -0,0 +1,16 @@ +#include "util.h" // msr_feature_control_setup +#include "x86.h" // wrmsr +#include "romfile.h" // romfile_find + +u64 feature_control_bits; + +void msr_feature_control_setup(void) +{ + struct romfile_s *f = romfile_find("etc/msr_feature_control"); + if (!f) + return; + + f->copy(f, &feature_control_bits, sizeof(feature_control_bits)); + if (feature_control_bits) + wrmsr(MSR_IA32_FEATURE_CONTROL, feature_control_bits); +} diff --git a/src/fw/paravirt.c b/src/fw/paravirt.c index 8ed4380..640ee4c 100644 --- a/src/fw/paravirt.c +++ b/src/fw/paravirt.c @@ -153,6 +153,9 @@ qemu_platform_setup(void) mtrr_setup(); smp_setup(); + // Initialize MSR_IA32_FEATURE_CONTROL + msr_feature_control_setup(); + // Create bios tables pirtable_setup(); mptable_setup(); diff --git a/src/fw/smp.c b/src/fw/smp.c index 579acdb..8b57bf4 100644 --- a/src/fw/smp.c +++ b/src/fw/smp.c @@ -10,7 +10,7 @@ #include "output.h" // dprintf #include "romfile.h" // romfile_loadint #include "stacks.h" // yield -#include "util.h" // smp_setup +#include "util.h" // smp_setup, msr_feature_control_setup #include "x86.h" // wrmsr #define APIC_ICR_LOW ((u8*)BUILD_APIC_ADDR + 0x300) @@ -63,6 +63,10 @@ handle_smp(void) for (i=0; i<smp_mtrr_count; i++) wrmsr(smp_mtrr[i].index, smp_mtrr[i].val); + // MSR_IA32_FEATURE_CONTROL setup + if (feature_control_bits) + wrmsr(MSR_IA32_FEATURE_CONTROL, feature_control_bits); + // Set bit on FoundAPICIDs FoundAPICIDs[apic_id/32] |= (1 << (apic_id % 32)); diff --git a/src/util.h b/src/util.h index 7b41207..fc8e59d 100644 --- a/src/util.h +++ b/src/util.h @@ -103,6 +103,11 @@ int csm_bootprio_pci(struct pci_device *pci); // fw/mptable.c void mptable_setup(void); +// fw/msr_feature_control.c +#define MSR_IA32_FEATURE_CONTROL 0x0000003a +extern u64 feature_control_bits; +void msr_feature_control_setup(void); + // fw/mtrr.c void mtrr_setup(void); -- 2.9.0

2 3

How can I pass command line options to secondary payload?
by Dustin Brazeau June 9, 2016

June 9, 2016

I am booting SeaBIOS as a payload of coreboot. I am then booting memtest86 as a secondary payload from SeaBIOS. It looks like memtest86 support command line options, but I can't figure out how to pass a command line to a secondary payload from SeaBIOS. Looks like it is somehow related to the multiboot option in SeaBIOS, which I have tried enabling, but I still can't figure out how add and pass a command line to a payload ran from SeaBIOS.

1 0

Re: [SeaBIOS] [coreboot] UEFI project ideas
by Laszlo Ersek June 7, 2016

June 7, 2016

On 06/07/16 16:35, Zoran Stojsavljevic wrote: >> Note that you can build seabios as CSM for tianocore already. > > These are the opposites: SeaBIOS is CSM ON (emulates Leagcy BIOS), while > Tiano Core supposed to be CSM OFF (UEFI), Thus, SeaBIOS and Tiano Core > exclude each other (should not be used together -> wrong architecture). SeaBIOS can be built and used as a CSM with UEFI firmware built from tianocore/edk2. The projects themselves are not "opposites". The resultant firmware binary can boot OSes in UEFI mode or in legacy mode. I guess those boot modes can be called opposites. >> What is the point? You can just run tianocore as coreboot playload. > > The point is to make minimal Tiano Core (minimum for making FAT32 > partition/file system on HDD/SDD to create /boot/EFI/ directory, in > other words minimal UEFI compliant BIOS), Tiano Core as such is good to > be used/run for/on x86 architecture ONLY This is patently false. Several aarch64 platforms exist that run UEFI firmware based more or less directly on tianocore/edk2. In my living room I have an APM Mustang that has UEFI firmware, based on tianocore/edk2. The SBBR spec (Server Base Boot Requirements System Software on ARM ® Platforms) mandates UEFI. Of course, not all ARM platforms are required to conform to the SBBR, but the SBBR would be quite foolish to require a practically unfeasible thing. tianocore/edk2 is the open source reference implementation of PI (Platform Init) and UEFI. It's a separate question wheter specific aarch64 platform code lives directly within the edk2 tree, or in some external tree (open source or proprietary). > (and side effect is the > extended time for booting, since all these DXE drivers must be > installed, which will be later mostly replaced/run over with OS drivers, > except run time services). DXE drivers are supposed to drive peripherals only in the exceptional case. Most devices that are not integrated in the platform are supposed to be driven by UEFI drivers that conform to the UEFI Driver Model. The point of that driver model is that no compliant driver, when initially launched, starts to drive any kind of hardware. Instead, it installs only three callbacks (member functions of its driver binding protocol instance): supported, start, and stop. The supported callback is used as a very quick check by the system to see if a driver supports a given piece of hardware. The start and stop functions instruct the driver to actually bind (and unbind) the specified piece of hardware. The calls to the supported and bind functions are initiated by Platform BDS (Boot Device Selection). In other words, it is a platform decision to automatically bind this or that set of devices. In OVMF and ArmVirtPkg (running in QEMU, Xen, and possibly other virtual machines), we choose to automatically bind all possible devices, because in virt, that's generally the best approach (and it is even necessary for some QEMU boot order quirks that I'm not going to go into now). But, auto-binding all devices is nowhere mandated by the UEFI spec, or any other related spec. In fact, on some x86 platforms the vendor seeks to speed up the boot by not connecting USB keyboards even. (And then, if you want to use the USB keyboard before the OS is booted, for example for modifying firmware settings, you have to set a non-volatile UEFI variable from within the OS, sometimes displayed as "change firmware settings" or some such. Then at the next boot, the firmware will drop you into the setup TUI, with the keyboard (and possibly other devices) connected. The user can massage firmware settings then; e.g., if the platform vendor wants it too, the user may be able to add the USB keyboard to the set of auto-connected devices.) Other schemes exist too. The Platform Init specification (separate from the UEFI specification) defines the Boot Mode HOB (hand-off block). The HOB-producer phase of the firmware (usually: PEI, Pre-EFI Initialization) can produce this HOB, so that later phases of the firmware can key off of it. For example, dependent on platform hardware support, this HOB can tell the Boot Device Selection phase *not* to connect any other devices than the last time around, because the chassis has not been opened since. Otherwise, BDS might want to auto-connect everything (perhaps the user installed a new SSD, etc). > As such, Minimal Tiano Core (minimal UEFI compliant BIOS) could be used > on ARM architectures too, thus making ARM HW platforms also > compatible/lookalike as x86 UEFI compliant BIOS. The UEFI specification already contains AArch32 and AArch64 bindings. It is already possible to implement UEFI on ARM platforms, and several vendors have. Boot performance, as far as it is affected by the set of devices automatically connected, is platform policy. > In nutshell, then you can build PC/Laptop with ARM CPU/SoC HW platform, >From last September, a blog post from one of my colleagues: https://marcin.juszkiewicz.com.pl/2015/09/21/aarch64-desktop-day-one/ > having coreboot + minimal Tiano Core + WIN 10 Boot Loader + WIN10 on it > (since WIN10 BL does see UEFI compliance, not knowing what is really > under the hood). ;-) For the record, I am definitely not arguing against coreboot, or u-boot, or even a stripped down platform firmware built purely from tianocore/edk2. Still for the record, I'm also not arguing that people should move to UEFI *at all*, unless they have specific reasons. But claiming that tianocore/edk2 is only good for x86 in its current shape and form, and implying that UEFI on ARM unconditionally needs a lower-level "shim", are just preposterous. Laszlo

2 1

Re: [SeaBIOS] [coreboot] UEFI project ideas
by Martin Roth June 7, 2016

June 7, 2016

Here's a patch to build the UEFI coreboot payload package directly as a coreboot payload. https://review.coreboot.org/#/c/15057/ Martin On Tue, Jun 7, 2016 at 1:13 PM, Zoran Stojsavljevic < zoran.stojsavljevic(a)gmail.com> wrote: > > I fail to see what you are trying to tell me. > > I'm not sure you even know what a CSM is. > > I probably do not. ;-) > > > And what has all this to do with seabios? > > Did I ever mention SeaBIOS to play minimal TianoCore? > > Thank you, > Zoran > > On Tue, Jun 7, 2016 at 5:18 PM, Gerd Hoffmann <kraxel(a)redhat.com> wrote: > >> On Di, 2016-06-07 at 16:35 +0200, Zoran Stojsavljevic wrote: >> > > Note that you can build seabios as CSM for tianocore already. >> >> > These are the opposites: SeaBIOS is CSM ON (emulates Leagcy BIOS), >> > while Tiano Core supposed to be CSM OFF (UEFI), Thus, SeaBIOS and >> > Tiano Core exclude each other (should not be used together -> wrong >> > architecture). >> >> I fail to see what you are trying to tell me. >> I'm not sure you even know what a CSM is. >> >> > > What is the point? You can just run tianocore as coreboot playload. >> >> > The point is to make minimal Tiano Core (minimum for making FAT32 >> > partition/file system on HDD/SDD to create /boot/EFI/ directory, in >> > other words minimal UEFI compliant BIOS), Tiano Core as such is good >> > to be used/run for/on x86 architecture ONLY (and side effect is the >> > extended time for booting, since all these DXE drivers must be >> > installed, which will be later mostly replaced/run over with OS >> > drivers, except run time services). >> >> > As such, Minimal Tiano Core (minimal UEFI compliant BIOS) could be >> > used on ARM architectures too, thus making ARM HW platforms also >> > compatible/lookalike as x86 UEFI compliant BIOS. >> >> tianocore already runs on arm. >> seabios doesn't and it never will. >> >> > In nutshell, then you can build PC/Laptop with ARM CPU/SoC HW >> > platform, having coreboot + minimal Tiano Core + WIN 10 Boot Loader + >> > WIN10 on it (since WIN10 BL does see UEFI compliance, not knowing what >> > is really under the hood). ;-) >> >> And what has all this to do with seabios? >> >> confused, >> Gerd >> >> > > -- > coreboot mailing list: coreboot(a)coreboot.org > https://www.coreboot.org/mailman/listinfo/coreboot >

1 0

Re: [SeaBIOS] [coreboot] UEFI project ideas
by Gerd Hoffmann June 7, 2016

June 7, 2016

On Di, 2016-06-07 at 16:35 +0200, Zoran Stojsavljevic wrote: > > Note that you can build seabios as CSM for tianocore already. > These are the opposites: SeaBIOS is CSM ON (emulates Leagcy BIOS), > while Tiano Core supposed to be CSM OFF (UEFI), Thus, SeaBIOS and > Tiano Core exclude each other (should not be used together -> wrong > architecture). I fail to see what you are trying to tell me. I'm not sure you even know what a CSM is. > > What is the point? You can just run tianocore as coreboot playload. > The point is to make minimal Tiano Core (minimum for making FAT32 > partition/file system on HDD/SDD to create /boot/EFI/ directory, in > other words minimal UEFI compliant BIOS), Tiano Core as such is good > to be used/run for/on x86 architecture ONLY (and side effect is the > extended time for booting, since all these DXE drivers must be > installed, which will be later mostly replaced/run over with OS > drivers, except run time services). > As such, Minimal Tiano Core (minimal UEFI compliant BIOS) could be > used on ARM architectures too, thus making ARM HW platforms also > compatible/lookalike as x86 UEFI compliant BIOS. tianocore already runs on arm. seabios doesn't and it never will. > In nutshell, then you can build PC/Laptop with ARM CPU/SoC HW > platform, having coreboot + minimal Tiano Core + WIN 10 Boot Loader + > WIN10 on it (since WIN10 BL does see UEFI compliance, not knowing what > is really under the hood). ;-) And what has all this to do with seabios? confused, Gerd

2 1

UEFI project ideas
by Rudolf Marek June 7, 2016

June 7, 2016

Hi all, I noticed that seabios/libpayload could have interresting use cases and I want to share/discuss them. 1) Have a SeaBIOS be a UEFI application. This would benefit on UEFI platforms without CSM. 2) Provide a minimum UEFI environment. As I noticed u-boot started to have such support. In fact it has UEFI glue to u-boot drivers. As such it provides a minimal boot services + minimum runtime services. In seabios, it is almost there, only PE loader and filesystem support is missing. The 2) could be perhaps be some independent project utilizing the coreboot libpayload library. Maybe those can be done in next year GSoC. I guess 2) could be useful to boot future OSes without legacy support. Thanks Rudolf

4 4

[PATCH]:splash: Skip the RGB555 mode
by Zheng Bao June 2, 2016

June 2, 2016

Current JPEG decoding uses the RGB888 or RGB565. So we need to skip RGB555 mode. Signed-off-by: Zheng Bao <fishbaozi(a)gmail.com> --- src/bootsplash.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/bootsplash.c b/src/bootsplash.c index c572685..d6990fc 100644 --- a/src/bootsplash.c +++ b/src/bootsplash.c @@ -81,7 +81,7 @@ find_videomode(struct vbe_info *vesa_info, struct vbe_mode_info *mode_info continue; u8 depth = mode_info->bits_per_pixel; if (bpp_req == 0) { - if (depth != 16 && depth != 24 && depth != 32) + if ((depth != 16 && depth != 24 && depth != 32) || mode_info->green_size == 5) continue; } else { if (depth != bpp_req)

2 1

KVM Forum 2016: Call For Participation
by Paolo Bonzini June 1, 2016

June 1, 2016

================================================================= KVM Forum 2016: Call For Participation August 24-26, 2016 - Westin Harbor Castle - Toronto, Canada (All submissions must be received before midnight May 1, 2016) ================================================================= KVM Forum is an annual event that presents a rare opportunity for developers and users to meet, discuss the state of Linux virtualization technology, and plan for the challenges ahead. We invite you to lead part of the discussion by submitting a speaking proposal for KVM Forum 2016. At this highly technical conference, developers driving innovation in the KVM virtualization stack (Linux, KVM, QEMU, libvirt) can meet users who depend on KVM as part of their offerings, or to power their data centers and clouds. KVM Forum will include sessions on the state of the KVM virtualization stack, planning for the future, and many opportunities for attendees to collaborate. As we celebrate ten years of KVM development in the Linux kernel, KVM continues to be a critical part of the FOSS cloud infrastructure. This year, KVM Forum is joining LinuxCon and ContainerCon in Toronto, Canada. Selected talks from KVM Forum will be presented on Wednesday August 24 to the full audience of LinuxCon and ContainerCon. Also, attendees of KVM Forum will have access to all of the LinuxCon and ContainerCon talks on Wednesday. http://events.linuxfoundation.org/cfp Suggested topics: KVM and Linux * Scaling and optimizations * Nested virtualization * Linux kernel performance improvements * Resource management (CPU, I/O, memory) * Hardening and security * VFIO: SR-IOV, GPU, platform device assignment * Architecture ports QEMU * Management interfaces: QOM and QMP * New devices, new boards, new architectures * Scaling and optimizations * Desktop virtualization and SPICE * Virtual GPU * virtio and vhost, including non-Linux or non-virtualized uses * Hardening and security * New storage features * Live migration and fault tolerance * High availability and continuous backup * Real-time guest support * Emulation and TCG * Firmware: ACPI, UEFI, coreboot, u-Boot, etc. * Testing Management and infrastructure * Managing KVM: Libvirt, OpenStack, oVirt, etc. * Storage: glusterfs, Ceph, etc. * Software defined networking: Open vSwitch, OpenDaylight, etc. * Network Function Virtualization * Security * Provisioning * Performance tuning =============== SUBMITTING YOUR PROPOSAL =============== Abstracts due: May 1, 2016 Please submit a short abstract (~150 words) describing your presentation proposal. Slots vary in length up to 45 minutes. Also include the proposal type -- one of: - technical talk - end-user talk Submit your proposal here: http://events.linuxfoundation.org/cfp Please only use the categories "presentation" and "panel discussion" You will receive a notification whether or not your presentation proposal was accepted by May 27, 2016. Speakers will receive a complimentary pass for the event. In the instance that your submission has multiple presenters, only the primary speaker for a proposal will receive a complementary event pass. For panel discussions, all panelists will receive a complimentary event pass. TECHNICAL TALKS A good technical talk should not just report on what has happened over the last year; it should present a concrete problem and how it impacts the user and/or developer community. Whenever applicable, focus on work that needs to be done, difficulties that haven't yet been solved, and on decisions that other developers should be aware of. Summarizing recent developments is okay but it should not be more than a small portion of the overall talk. END-USER TALKS One of the big challenges as developers is to know what, where and how people actually use our software. We will reserve a few slots for end users talking about their deployment challenges and achievements. If you are using KVM in production you are encouraged submit a speaking proposal. Simply mark it as an end-user talk. As an end user, this is a unique opportunity to get your input to developers. HANDS-ON / BOF SESSIONS We will reserve some time for people to get together and discuss strategic decisions as well as other topics that are best solved within smaller groups. These sessions will be announced during the event. If you are interested in organizing such a session, please add it to the list at http://www.linux-kvm.org/page/KVM_Forum_2016_BOF Let people you think might be interested know about it, and encourage them to add their names to the wiki page as well. Please try to add your ideas to the list before KVM Forum starts. PANEL DISCUSSIONS If you are proposing a panel discussion, please make sure that you list all of your potential panelists in your abstract. We will request full biographies if a panel is accepted. =============== HOTEL / TRAVEL =============== This year's event will take place at the Westin Harbour Castle Toronto. For information on discounted room rates for conference attendees and on other hotels close to the conference, please visit http://events.linuxfoundation.org/events/kvm-forum/attend/hotel-travel. As of March 15, 2016, non-US citizens need either a visa or an Electronic Travel Authorization (eTA) in order to enter Canada. Detailed information on the travel documentation required for your country of origin can be found at http://www.cic.gc.ca/english/visit/visas.asp and http://events.linuxfoundation.org/events/kvm-forum/attend/hotel-travel. ** We urge you to start this process as quickly as possible to ensure ** receipt of appropriate travel documentation in time for your conference ** travel to Canada. For processing times for visa applications, please visit ** http://www.cic.gc.ca/english/information/times/. =============== IMPORTANT DATES =============== Notification: May 27, 2015 Schedule announced: June 3, 2015 Event dates: August 24-26, 2016 Thank you for your interest in KVM. We're looking forward to your submissions and seeing you at the KVM Forum 2016 in August! -your KVM Forum 2016 Program Committee Please contact us with any questions or comments at kvm-forum-2016-pc(a)redhat.com

2 2

[PATCH v5] fw/pci: Add support for mapping Intel IGD via QEMU
by Alex Williamson June 1, 2016

June 1, 2016

QEMU provides two fw_cfg files to support IGD. The first holds the OpRegion data which holds the Video BIOS Table (VBT). This needs to be copied into reserved memory and the address stored in the ASL Storage register of the device at 0xFC offset in PCI config space. The OpRegion is generally 8KB. This file is named "etc/igd-opregion". The second file tells us the required size of the stolen memory space for the device. This space requires 1MB alignment and is generally either 1MB to 8MB depending on hardware config, but may be hundreds of MB for user specified stolen memory. The base address of the reserved memory allocated for this is written back to the Base Data of Stolen Memory register (BDSM) at PCI config offset 0x5C on the device. This file is named "etc/igd-bdsm-size". QEMU documents these fw_cfg entries in docs/igd-assign.txt. Signed-off-by: Alex Williamson <alex.williamson(a)redhat.com> --- v6: fw_cfg BDSM entry now holds an 8-byte size integer as suggested by Gerd. Also renamed to etc/igd-bdsm-size. Filter based on bdf to only make use of this for the Intel VGA device at address 00:02.0, not that QEMU should attach this to anything else. As always, comments appreciated. I expect this will be on hold pending the QEMU support: http://thread.gmane.org/gmane.comp.emulators.kvm.devel/152123 If there's a better way to sync these projects, please let me know. Thanks, Alex src/fw/pciinit.c | 48 ++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 48 insertions(+) diff --git a/src/fw/pciinit.c b/src/fw/pciinit.c index 35d9902..08221e6 100644 --- a/src/fw/pciinit.c +++ b/src/fw/pciinit.c @@ -287,6 +287,50 @@ static void ich9_smbus_setup(struct pci_device *dev, void *arg) ich9_smbus_enable(dev->bdf); } +static void intel_igd_setup(struct pci_device *dev, void *arg) +{ + struct romfile_s *opregion = romfile_find("etc/igd-opregion"); + u64 bdsm_size = le64_to_cpu(romfile_loadint("etc/igd-bdsm-size", 0)); + void *addr; + u16 bdf = dev->bdf; + + /* Apply OpRegion to any Intel VGA device, more than one is undefined */ + if (opregion && opregion->size) { + addr = memalign_high(PAGE_SIZE, opregion->size); + if (!addr) { + warn_noalloc(); + return; + } + + if (opregion->copy(opregion, addr, opregion->size) < 0) { + free(addr); + return; + } + + pci_config_writel(bdf, 0xFC, cpu_to_le32((u32)addr)); + + dprintf(1, "Intel IGD OpRegion enabled at 0x%08x, size %dKB, dev " + "%02x:%02x.%x\n", (u32)addr, opregion->size >> 10, + pci_bdf_to_bus(bdf), pci_bdf_to_dev(bdf), pci_bdf_to_fn(bdf)); + } + + /* Apply BDSM only to Intel VGA at 00:02.0 */ + if (bdsm_size && (bdf == pci_to_bdf(0, 2, 0))) { + addr = memalign_tmphigh(1024 * 1024, bdsm_size); + if (!addr) { + warn_noalloc(); + return; + } + + e820_add((u32)addr, bdsm_size, E820_RESERVED); + + pci_config_writel(bdf, 0x5C, cpu_to_le32((u32)addr)); + + dprintf(1, "Intel IGD BDSM enabled at 0x%08x, size %lldMB, dev " + "00:02.0\n", (u32)addr, bdsm_size >> 20); + } +} + static const struct pci_device_id pci_device_tbl[] = { /* PIIX3/PIIX4 PCI to ISA bridge */ PCI_DEVICE(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_82371SB_0, @@ -320,6 +364,10 @@ static const struct pci_device_id pci_device_tbl[] = { PCI_DEVICE_CLASS(PCI_VENDOR_ID_APPLE, 0x0017, 0xff00, apple_macio_setup), PCI_DEVICE_CLASS(PCI_VENDOR_ID_APPLE, 0x0022, 0xff00, apple_macio_setup), + /* Intel IGD OpRegion setup */ + PCI_DEVICE_CLASS(PCI_VENDOR_ID_INTEL, PCI_ANY_ID, PCI_CLASS_DISPLAY_VGA, + intel_igd_setup), + PCI_DEVICE_END, };

2 2