SeaBIOS

seabios@seabios.org

4 participants
3801 discussions

Re: [SeaBIOS] A20: ahci_process_op is called with A20 off
by Kevin O'Connor 11 May '17

11 May '17

On Wed, May 10, 2017 at 07:28:44PM +0000, Xu, Anthony wrote: > > From: Kevin O'Connor [mailto:kevin@koconnor.net] > > On Tue, May 09, 2017 at 08:39:07PM +0000, Xu, Anthony wrote: > > > I dig into seebios code, and found ahci_process_op is called with A20 off, > > > > > > The call trace is, > > > process_op_16->process_op_both->call32->call32_smm->process_op_32- > > >ahci_process_op > > > > > > call32_smm calls call32_prep, but because the method is C16_SMM, A20 is > > not enabled in call32_prep. > > > ahci_process_op is called with A20 off. > > > > As I understand it, entering System Managament Mode (SMM) should > > automatically enable A20, so it should not be necessary for call32_smm > > to enable it. Are you sure the issue is related to A20 instead of > > some other issue with SMM? > > I'm pretty sure the issue is related to A20, I'm not familiar with Seabios code, > I'm not sure why call32 needs to call32_smm. If my understanding is correct, > VCPU is not in SMM mode at the time. As background, seabios must support disk read/write requests when the x86 processor is in 16bit mode. There's some info on the modes seabios supports at: https://www.seabios.org/Memory_Model Unfortunately, some disk controllers can only be controlled when the processor is in 32bit mode - ahci is an example of this. So, to service these calls, seabios must switch from 16bit mode to 32bit mode, perform the disk operation, and then return to 16bit mode. SeaBIOS has a couple of different methods to accomplish this mode switching - it can directly switch modes (C16_BIG switch) or it can use a helper in SMM mode to perform the switch (C16_SMM). The preferred method is C16_SMM as C16_BIG isn't available in VM86 mode and it also clobbers the 16bit segment registers. If you don't want to use C16_SMM, you can turn off CONFIG_CALL32_SMM via "make menuconfig". It's still not clear to me why C16_SMM doesn't work though - as I think it should have saved and restored the A20 flag. -Kevin

2 1

Re: [SeaBIOS] A20: ahci_process_op is called with A20 off
by Kevin O'Connor 11 May '17

11 May '17

On Tue, May 09, 2017 at 08:39:07PM +0000, Xu, Anthony wrote: > Hi All, > > I recently met an issue, I can't boot my centos guest in below scenarios. > > I disabled kvmvapic by > > diff --git a/hw/intc/apic_common.c b/hw/intc/apic_common.c > index c3829e3..52be2b0 100644 > --- a/hw/intc/apic_common.c > +++ b/hw/intc/apic_common.c > @@ -440,7 +440,7 @@ static const VMStateDescription vmstate_apic_common = { > static Property apic_properties_common[] = { > DEFINE_PROP_UINT8("version", APICCommonState, version, 0x14), > DEFINE_PROP_BIT("vapic", APICCommonState, vapic_control, VAPIC_ENABLE_BIT, > - true), > + false), > DEFINE_PROP_BOOL("legacy-instance-id", APICCommonState, legacy_instance_id, > false), > DEFINE_PROP_END_OF_LIST(), > > > I run Qemu in TCG mode > > ./x86_64-softmmu/qemu-system-x86_64 -bios /home/root/git/seabios/out/bios.bin -machine q35 > -m 1G -drive format=raw,file=/home/root/images/centos7.2.img,if=ide,index=0 -nographic > -nodefaults -serial stdio -monitor pty > > It can't boot with below message, > " > Booting from Hard Disk... > WARNING - Timeout at ahci_command:154! > Boot failed: could not read the boot disk > > enter handle_18: > NULL > Booting from Floppy... > Boot failed: could not read the boot disk > " > > Once I add kvmvapic , it can boot. > > I dig into seebios code, and found ahci_process_op is called with A20 off, > > The call trace is, > process_op_16->process_op_both->call32->call32_smm->process_op_32->ahci_process_op > > call32_smm calls call32_prep, but because the method is C16_SMM, A20 is not enabled in call32_prep. > ahci_process_op is called with A20 off. As I understand it, entering System Managament Mode (SMM) should automatically enable A20, so it should not be necessary for call32_smm to enable it. Are you sure the issue is related to A20 instead of some other issue with SMM? -Kevin

2 1

[PATCH] NVMe: Allow NVMe to be enabled on real hardware
by Kevin O'Connor 10 May '17

10 May '17

A couple of users have reported success with the NVMe driver on real hardware, so allow it to be enabled outside of QEMU. Signed-off-by: Kevin O'Connor <kevin(a)koconnor.net> --- src/Kconfig | 2 +- src/hw/nvme.c | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/src/Kconfig b/src/Kconfig index e1b83a4..77ec9c7 100644 --- a/src/Kconfig +++ b/src/Kconfig @@ -228,7 +228,7 @@ menu "Hardware support" Support floppy images stored in coreboot flash or from QEMU fw_cfg. config NVME - depends on DRIVES && QEMU_HARDWARE + depends on DRIVES bool "NVMe controllers" default y help diff --git a/src/hw/nvme.c b/src/hw/nvme.c index 60557ae..1c2bce5 100644 --- a/src/hw/nvme.c +++ b/src/hw/nvme.c @@ -618,7 +618,7 @@ void nvme_setup(void) { ASSERT32FLAT(); - if (!CONFIG_NVME || !runningOnQEMU()) + if (!CONFIG_NVME) return; dprintf(3, "init nvme\n"); -- 2.9.3

1 0

Re: [SeaBIOS] [PATCH 1/4] SeaVGABios/cbvga: Assume VGA compatible GPU in text-mode
by Patrick Rudolph 10 May '17

10 May '17

On Sat Mar 18 02:04:38 CET 2017, Kevin O'Connor wrote: >> Assume the GPU is VGA compatible when running in text-mode. >> Advertise VGA modes using SeaVGABios' stdvga driver. >> running in text mode, even when not advertised. >> >> Allows Windows 7 to boot in 640x480 and 16 colors mode using the >> VgaSave driver. >> Allows Windows 7 to show the loading bar splash screen. >> >> Known issues: >> The palette seems wrong, as colors are swapped ( blue is red, ... ). > >What graphics hardware did you test this on? > >If stdvga_set_mode() works on the hardware, why not use stdvga >seavgabios and get the rest of the vgabios functionality? (That is, >why use cbvga seavgabios at all?) I'm on Lenovo T500 (Intel Graphics Media Accelerator 4500MHD). I'm going to do some tests using stdvga instead of cbvga. Regards, Patrick

2 1

Re: [SeaBIOS] [Question] SeaBIOS: cannot boot oracle linux if increase the maximum size of permanent high memory area
by Kevin O'Connor 10 May '17

10 May '17

On Fri, May 05, 2017 at 10:49:05AM +0000, Gonglei (Arei) wrote: > Hi guys, > > Currently my workmate encountered an issues in the testing environment: > > A letter from him: > > In order to boot a BIG vm (with 4T mem, 255 vCPUs, 60 virtio-scsi > disk...), i have to increase the BUILD_MAX_HIGHTABLE to 512KB. But, > then i found i can not boot a specific VM anymore (oracle linux 6.7 > 64bits with kernel 3.8.13, 2G mem). It seems be related with the > unused high ram given VM back by SeaBios (maybe also related to the > memory align). I've tested if setting giveback memory 64KB > alignment other than 4KB, SeaBios with 512KB BUILD_MAX_HIGHTABLE can > boot the specific VM. But , i don't know the reason... > > As far as i know, if seabios does not give back the unused ZoneHigh > memory seems will not trigger any problems but just waste only a > little memory ,right? > > Can you tell me what's the worst effect if i apply the following patch? > > Does it influence live migration? The only downside I'm aware of is that it would waste a small amount of ram. I'm surprised that "oracle linux" has this issue. I can only see a few reasons for it to fail there - a "use after free" bug in seabios, oracle linux expects the ram to be zero'd, or oracle linux is expecting the e820 map to have an alignment larger than page size. The first seems unlikely as "permanent high ram" is rarely ever free'd in seabios. The second also seems unlikely. -Kevin

1 0

A20: ahci_process_op is called with A20 off
by Xu, Anthony 09 May '17

09 May '17

Hi All, I recently met an issue, I can't boot my centos guest in below scenarios. I disabled kvmvapic by diff --git a/hw/intc/apic_common.c b/hw/intc/apic_common.c index c3829e3..52be2b0 100644 --- a/hw/intc/apic_common.c +++ b/hw/intc/apic_common.c @@ -440,7 +440,7 @@ static const VMStateDescription vmstate_apic_common = { static Property apic_properties_common[] = { DEFINE_PROP_UINT8("version", APICCommonState, version, 0x14), DEFINE_PROP_BIT("vapic", APICCommonState, vapic_control, VAPIC_ENABLE_BIT, - true), + false), DEFINE_PROP_BOOL("legacy-instance-id", APICCommonState, legacy_instance_id, false), DEFINE_PROP_END_OF_LIST(), I run Qemu in TCG mode ./x86_64-softmmu/qemu-system-x86_64 -bios /home/root/git/seabios/out/bios.bin -machine q35 -m 1G -drive format=raw,file=/home/root/images/centos7.2.img,if=ide,index=0 -nographic -nodefaults -serial stdio -monitor pty It can't boot with below message, " Booting from Hard Disk... WARNING - Timeout at ahci_command:154! Boot failed: could not read the boot disk enter handle_18: NULL Booting from Floppy... Boot failed: could not read the boot disk " Once I add kvmvapic , it can boot. I dig into seebios code, and found ahci_process_op is called with A20 off, The call trace is, process_op_16->process_op_both->call32->call32_smm->process_op_32->ahci_process_op call32_smm calls call32_prep, but because the method is C16_SMM, A20 is not enabled in call32_prep. ahci_process_op is called with A20 off. ahci_process_op accesses memory mapped IO to operate ahci, the IO is mapped to 0xfebff000, because a20 is disabled, the bit 20 of 0xfebff000 is set 0 , which is 0xfeaff000, an iotlb entry mapping 0xfebff000 to 0xfeaff000 is added to iotlb cache. So ahci_process_op actually accesses 0xfeaff000, it obviously won't work. target/i386/helper.c do_mapping: pte = pte & env->a20_mask; Why does guest boot with kvmvapic? In above scenario, there is no option roms. After adding kvmvapic, there is one option rom kvmvapic rom, and __callrom is called for kvmvapic rom. __callrom->farcall16big-> call16_override, once call16_override is called, a20 is enabled and will not be disabled. So ahci_process_op is called with a20 on. I tried below change, guest can boot without kvmvapic. I'm not familiar with seabios code, I don't consider it as a patch, but it proves my analysis is correct. With the change, __call32 calls call32_prep with method C16_BIG to enable a20 before calling ahci_process_op. please help fix this issue. Thanks, Anthony diff --git a/src/stacks.c b/src/stacks.c index ef6a707..0949652 100644 --- a/src/stacks.c +++ b/src/stacks.c @@ -232,10 +237,11 @@ u32 VISIBLE16 __call32(void *func, u32 eax, u32 errret) { ASSERT16(); - if (CONFIG_CALL32_SMM && GET_GLOBAL(HaveSmmCall32)) - return call32_smm(func, eax); +// if (CONFIG_CALL32_SMM && GET_GLOBAL(HaveSmmCall32)) +// return call32_smm(func, eax); // Jump direclty to 32bit mode - this clobbers the 16bit segment // selector registers.

1 0

[Question] SeaBIOS: cannot boot oracle linux if increase the maximum size of permanent high memory area
by Gonglei (Arei) 05 May '17

05 May '17

Hi guys, Currently my workmate encountered an issues in the testing environment: A letter from him: In order to boot a BIG vm (with 4T mem, 255 vCPUs, 60 virtio-scsi disk...), i have to increase the BUILD_MAX_HIGHTABLE to 512KB. But, then i found i can not boot a specific VM anymore (oracle linux 6.7 64bits with kernel 3.8.13, 2G mem). It seems be related with the unused high ram given VM back by SeaBios (maybe also related to the memory align). I've tested if setting giveback memory 64KB alignment other than 4KB, SeaBios with 512KB BUILD_MAX_HIGHTABLE can boot the specific VM. But , i don't know the reason... As far as i know, if seabios does not give back the unused ZoneHigh memory seems will not trigger any problems but just waste only a little memory ,right? Can you tell me what's the worst effect if i apply the following patch? Does it influence live migration? Thanks! diff --git a/src/config.h b/src/config.h index baca029..b3536f1 100644 index baca029..b3536f1 100644 --- a/src/config.h +++ b/src/config.h @@ -17,7 +17,7 @@ // Maximum number of map entries in the e820 map #define BUILD_MAX_E820 32 // Space to reserve in high-memory for tables -#define BUILD_MAX_HIGHTABLE (256*1024) +#define BUILD_MAX_HIGHTABLE (512*1024) diff --git a/src/malloc.c b/src/malloc.c index 3733855..6302525 100644 --- a/src/malloc.c +++ b/src/malloc.c @@ -549,13 +549,7 @@ malloc_prepboot(void) dprintf(1, "Space available for UMB: %x-%x, %x-%x\n" , RomEnd, base, info->range_start, info->range_end); - // Give back unused high ram. - info = alloc_find_lowest(&ZoneHigh); - if (info) { - u32 giveback = ALIGN_DOWN(info->range_end-info->range_start, PAGE_SIZE); - e820_add(info->range_start, giveback, E820_RAM); - dprintf(1, "Returned %d bytes of ZoneHigh\n", giveback); - } calcRamSize(); Regards, -Gonglei

1 0

[Question] can not boot oracle linux if increase the maximum size of permanent high memory area
by Xulei (Stone) 04 May '17

04 May '17

Hi，can you tell me what's the worst effect if i apply the following patch? In order to boot a BIG vm (with 4T mem, 255 vCPUs, 60 virtio-scsi disk...), i have to increase the BUILD_MAX_HIGHTABLE to 512KB. But, then i found i can not boot a specific VM anymore (oracle linux 6.7 64bits with kernel 3.8.13, 2G mem). It seems be related with the unused high ram given VM back by SeaBios (maybe also related to the memory align). I've tested if setting giveback memory 64KB alignment other than 4KB, SeaBios with 512KB BUILD_MAX_HIGHTABLE can boot the specific VM. But , i don't know the reason... As far as i know, if seabios does not give back the unused ZoneHigh memory seems will not trigger any problems but just waste only a little memory ,right? diff --git a/src/config.h b/src/config.h index baca029..b3536f1 100644 index baca029..b3536f1 100644 --- a/src/config.h +++ b/src/config.h @@ -17,7 +17,7 @@ // Maximum number of map entries in the e820 map #define BUILD_MAX_E820 32 // Space to reserve in high-memory for tables -#define BUILD_MAX_HIGHTABLE (256*1024) +#define BUILD_MAX_HIGHTABLE (512*1024) diff --git a/src/malloc.c b/src/malloc.c index 3733855..6302525 100644 --- a/src/malloc.c +++ b/src/malloc.c @@ -549,13 +549,7 @@ malloc_prepboot(void) dprintf(1, "Space available for UMB: %x-%x, %x-%x\n" , RomEnd, base, info->range_start, info->range_end); - // Give back unused high ram. - info = alloc_find_lowest(&ZoneHigh); - if (info) { - u32 giveback = ALIGN_DOWN(info->range_end-info->range_start, PAGE_SIZE); - e820_add(info->range_start, giveback, E820_RAM); - dprintf(1, "Returned %d bytes of ZoneHigh\n", giveback); - } calcRamSize(); ________________________________

1 0

[PATCH v2 0/9] add support for generic lun enumeration
by Roman Kagan 03 May '17

03 May '17

A number of SCSI drivers currently only see luns #0 in their targets. This may be a problem when drives have to be assigned bigger lun numbers, e.g. because the storage controllers don't provide enough target numbers to accomodate all drives. (In particular, I'm about to submit a driver for Hyper-V VMBus SCSI controller which is limited to 2 targets only). This series adds generic SCSI lun enumeration (either via REPORT LUNS command or sequentially trying every lun), and makes the respective drivers use it. Note that the series has only been minimally tested against a recent QEMU. Roman Kagan (9): blockcmd: accept only disks and CD-ROMs blockcmd: generic SCSI luns enumeration virtio-scsi: enumerate luns with REPORT LUNS esp-scsi: enumerate luns with REPORT LUNS usb-uas: enumerate luns with REPORT LUNS pvscsi: fix the comment about lun enumeration mpt-scsi: try to enumerate luns with REPORT LUNS lsi-scsi: reset in case of a serious problem lsi-scsi: try to enumerate luns with REPORT LUNS Signed-off-by: Roman Kagan <rkagan(a)virtuozzo.com> --- v1 -> v2: - use malloc_tmp instead of malloc_high - format the retry logic as a regular while{} loop - I left the interface as in v1 as the alternatives looked heavier - patches 1,3-9 are unchanged src/hw/blockcmd.h | 4 +++ src/hw/blockcmd.c | 97 ++++++++++++++++++++++++++++++++++++++++++++++++++++ src/hw/esp-scsi.c | 35 +++++++++++++------ src/hw/lsi-scsi.c | 39 +++++++++++++++------ src/hw/mpt-scsi.c | 40 ++++++++++++++-------- src/hw/pvscsi.c | 2 +- src/hw/usb-uas.c | 45 +++++++++++++++--------- src/hw/virtio-scsi.c | 38 +++++++++++++------- 8 files changed, 236 insertions(+), 64 deletions(-) -- 2.9.3

2 10

[PATCH] coreboot: Adapt to upstream CBMEM console changes
by Julius Werner 25 Apr '17

25 Apr '17

coreboot's CBMEM console format changed with https://review.coreboot.org/#/c/18301. This patch adapts the SeaBIOS implementation to support the new format. (SeaBIOS versions with this patch will continue to work fine with older version of coreboot. SeaBIOS versions without this patch may fail to log messages to the CBMEM console if run with newer versions of coreboot, but should not experience any more serious issues than that.) Signed-off-by: Julius Werner <jwerner(a)chromium.org> --- src/fw/coreboot.c | 21 +++++++++++++++------ 1 file changed, 15 insertions(+), 6 deletions(-) diff --git a/src/fw/coreboot.c b/src/fw/coreboot.c index 4957b80..7214f8a 100644 --- a/src/fw/coreboot.c +++ b/src/fw/coreboot.c @@ -80,10 +80,12 @@ struct cb_cbmem_ref { #define CB_TAG_CBMEM_CONSOLE 0x17 struct cbmem_console { - u32 buffer_size; - u32 buffer_cursor; - u8 buffer_body[0]; + u32 size; + u32 cursor; + u8 body[0]; } PACKED; +#define CBMC_CURSOR_MASK ((1 << 28) - 1) +#define CBMC_OVERFLOW (1 << 31) static struct cbmem_console *cbcon = NULL; static u16 @@ -220,9 +222,16 @@ void coreboot_debug_putc(char c) return; if (!cbcon) return; - u32 cursor = cbcon->buffer_cursor++; - if (cursor < cbcon->buffer_size) - cbcon->buffer_body[cursor] = c; + u32 cursor = cbcon->cursor & CBMC_CURSOR_MASK; + u32 flags = cbcon->cursor & ~CBMC_CURSOR_MASK; + if (cursor >= cbcon->size) + return; // Old coreboot version with legacy overflow mechanism. + cbcon->body[cursor++] = c; + if (cursor >= cbcon->size) { + cursor = 0; + flags |= CBMC_OVERFLOW; + } + cbcon->cursor = flags | cursor; } /**************************************************************** -- 2.12.2.816.g2cccc81164-goog

2 1

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

SeaBIOS