SeaBIOS

seabios@seabios.org

3783 discussions

TPM implementation
by Wim Vervoorn 16 Sep '16

16 Sep '16

Hello Kevin/Stefan, I can see a lot of work has been done already on the tpm implementation in SeaBIOS. Can you update me on the status of this? Should I still consider this to be work in progress or is this close to a stage where it can actually be used in a production level project? Best Regards, Wim Vervoorn Eltan B.V. Ambachtstraat 23 5481 SM Schijndel The Netherlands T : +31-(0)73-594 46 64 E : wvervoorn(a)eltan.com W : http://www.eltan.com "THIS MESSAGE CONTAINS CONFIDENTIAL INFORMATION. UNLESS YOU ARE THE INTENDED RECIPIENT OF THIS MESSAGE, ANY USE OF THIS MESSAGE IS STRICTLY PROHIBITED. IF YOU HAVE RECEIVED THIS MESSAGE IN ERROR, PLEASE IMMEDIATELY NOTIFY THE SENDER BY TELEPHONE +31-(0)73-5944664 OR REPLY EMAIL, AND IMMEDIATELY DELETE THIS MESSAGE AND ALL COPIES."

1 0

Re: [SeaBIOS] [Qemu-devel] [RFC PATCH v2 00/12] Guest startup time optimization
by Gerd Hoffmann 13 Sep '16

13 Sep '16

Hi, > > AFAIK latest seabios already supports DMA. > > It's easy to add more config options for seabios > > if you are so inclined. > > Yes, I tried that, the fw_cfg overhead in SeaBios/linuxboot optrom is > already not a big issue for us. However, there are still some other > code in SeaBIOS needs to be investigated. What exactly? Also a few suggestions: * Try the seabios master branch. There have been some improvements recently which are not in the 1.9 release. * Use a stripped down config. When booting a kernel directly you don't need storage and usb drivers, also no keyboard. That all reduces init time. * Initializing all pci devices (placing bars in address space and programming them) can probably be skipped and left to the linux kernel to handle. But when trying take care that the effect might be that we shift just startup time from seabios to linux kernel, the placement needs to happen somewhere after all. * When discussing these things add the seabios list (seabios(a)seabios.org) to cc: Added the list now. cheers, Gerd

2 1

[PATCH] pci: don't map virtio 1.0 storage devices above 4G
by Marcel Apfelbaum 13 Sep '16

13 Sep '16

Otherwise SeaBIOS can't access virtio's modern BAR. Signed-off-by: Marcel Apfelbaum <marcel(a)redhat.com> --- Hi, If there is no room to map all MMIO BARs into the 32-bit PCI window, SeaBIOS will re-allocate all 64-bit MMIO BARs into over-4G space. Virtio 1.0 block devices (virtio-blk/virtio-scsi) use a 64-bit BAR unusable by SeaBIOS if mapped over 4G space, preventing the system to boot. The simplest solution is to follow the xhci model and simply skip migrating the virtio 1.0 modern bar into over-4G space. In order to reproduce the problem use: -device virtio-blk-pci, ...\ -object memory-backend-file,id=mem,size=4G,mem-path=/dev/hugepages,share=on \ -device ivshmem-plain,memdev=mem \ Thanks, Marcel src/fw/pciinit.c | 7 +++++++ 1 file changed, 7 insertions(+) diff --git a/src/fw/pciinit.c b/src/fw/pciinit.c index 35d9902..3b76e66 100644 --- a/src/fw/pciinit.c +++ b/src/fw/pciinit.c @@ -655,6 +655,13 @@ static void pci_region_migrate_64bit_entries(struct pci_region *from, continue; if (entry->dev->class == PCI_CLASS_SERIAL_USB) continue; + if (entry->dev->vendor == PCI_VENDOR_ID_REDHAT_QUMRANET && + (entry->dev->device == PCI_DEVICE_ID_VIRTIO_BLK_09 || + entry->dev->device == PCI_DEVICE_ID_VIRTIO_BLK_10 || + entry->dev->device == PCI_DEVICE_ID_VIRTIO_SCSI_09 || + entry->dev->device == PCI_DEVICE_ID_VIRTIO_SCSI_10)) + continue; + // Move from source list to destination list. hlist_del(&entry->node); hlist_add(&entry->node, last); -- 2.5.5

4 5

[PATCH 00/10] Improved keyboard key mappings
by Kevin O'Connor 13 Sep '16

13 Sep '16

There were several keys not mapped in the keyboard scancode to "keycode" mapping functions. This series adds in a number of additional keyboard mappings. I used the Phoenix "System BIOS for IBM PC/XT/AT Computers and Compatibles" book as a reference for the mappings. Albert - can you test if this series fixes your issue with the SysReq key? I've also uploaded the series to: https://github.com/KevinOConnor/seabios/tree/testing FYI, I've found on my Linux/X-Windows setup that QEMU doesn't always pass the correct keycodes for SysReq and Break to the guest. But, I've tested on real hardware to confirm that the keyboard mappings are correct. -Kevin Kevin O'Connor (10): kbd: Implement 101-key keyboard keycode mapping kbd: Implement extended keycode mappings for keypad-enter and keypad-/ kbd: Suppress keys without mappings kbd: Merge bda->kbd_flag0 and bda->kbd_flag1 kbd: Extract out shift flag setting into new function kbd: Move checking for special keys in __process_keys() into switch kbd: Ignore fake shift keys usb-hid: Generate Ctrl+Break and Alt+SysReq keys kbd: Generate interrupt events for SysReq, PrtScr, and Break post: Map int 0x05 to entry point src/hw/usb-hid.c | 50 +++++--- src/kbd.c | 383 ++++++++++++++++++++++++++++++------------------------- src/post.c | 1 + src/romlayout.S | 2 + src/std/bda.h | 26 +++- 5 files changed, 268 insertions(+), 194 deletions(-) -- 2.5.5

1 11

[PATCH] pic: The default hardware interrupt handlers should not take a parameter
by Kevin O'Connor 31 Aug '16

31 Aug '16

Hardware interrupt handlers don't take a parameter. Remove the incorrect (and unused) parameter from handle_hwpic1/2(). Signed-off-by: Kevin O'Connor <kevin(a)koconnor.net> --- src/hw/pic.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/src/hw/pic.c b/src/hw/pic.c index d8b9764..a13564a 100644 --- a/src/hw/pic.c +++ b/src/hw/pic.c @@ -101,14 +101,14 @@ pic_isr2_read(void) // Handler for otherwise unused hardware irqs. void VISIBLE16 -handle_hwpic1(struct bregs *regs) +handle_hwpic1(void) { dprintf(DEBUG_ISR_hwpic1, "handle_hwpic1 irq=%x\n", pic_isr1_read()); pic_eoi1(); } void VISIBLE16 -handle_hwpic2(struct bregs *regs) +handle_hwpic2(void) { dprintf(DEBUG_ISR_hwpic2, "handle_hwpic2 irq=%x\n", pic_isr2_read()); pic_eoi2(); -- 2.5.5

1 1

hw/usb-msc.c: Branch condition evaluates to a garbage value
by Paul Menzel 31 Aug '16

31 Aug '16

Dear SeaBIOS developers, Building the attached configuration with GCC 5.3.0 and the static analyzer scan-build shipped with Clang 3.8, the following error is reported in `src/hw/usb-msc.c` in line 110. The static analyzer seems to think that the struct member is not initialized. But I guess it’s done in the line below, and therefore a false positive? ``` ret = usb_msc_send(udrive_gf, USB_DIR_IN , MAKE_FLATPTR(GET_SEG(SS), &csw), sizeof(csw)); ``` Thanks, Paul

2 1

alt-sysrq support
by Albert Cahalan 26 Aug '16

26 Aug '16

This is a patch that worked for the Bochs BIOS. The code is similar. The important part is the keycode. DOSRMX needs this for console switching. The other part is a hook. I have key presses; key releases should be done too. I don't know what uses this, but it is a standard BIOS feature.

1 0

Show bootsplash already during device detection?
by Paul Menzel 24 Aug '16

24 Aug '16

Dear SeaBIOS folks, Playing with the bootsplash feature, I noticed, that it’s only displayed when the boot menu is displayed, when no bootsplash is used. On the ASRock E350M1 it takes ten seconds to detect the connected spinning hard disk, and the bootsplash is not displayed during that time. Would it make sense to already show the bootsplash then? Thanks, Paul

2 1

[PATCH] ps2: Remove stale check for timeout warning on reset
by Kevin O'Connor 22 Aug '16

22 Aug '16

Commit 4ce5d207 removed the code to wait for a possible second byte from a keyboard reset command, but it did not remove the extra check when warning in ps2_recvbyte(). Remove the now stale code in ps2_recvbyte(). Signed-off-by: Kevin O'Connor <kevin(a)koconnor.net> --- src/hw/ps2port.c | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/src/hw/ps2port.c b/src/hw/ps2port.c index d5504f7..d9727d2 100644 --- a/src/hw/ps2port.c +++ b/src/hw/ps2port.c @@ -179,9 +179,7 @@ ps2_recvbyte(int aux, int needack, int timeout) } if (timer_check(end)) { - // Don't warn on second byte of a reset - if (timeout > 100) - warn_timeout(); + warn_timeout(); return -1; } yield(); -- 2.5.5

1 1

Re: [SeaBIOS] [QUESTION]stuck in SeaBIOS and vm cannot be reset any more
by Xulei (Stone) 12 Aug '16

12 Aug '16

> On 11/08/2016 04:13, Xulei (Stone) wrote: > > Following your suggestion, I found this problem may be caused by the > > flag of HF_SMM_MASK. I'm now sure QEMU is sending the KVM_SMI ioctl, > > and kmod already handles this ioctl. > > > > I add printk in inject_pending_event(), like this: > > > > /* try to inject new event if pending */ > > + if(get_smi) > > + printk(KERN_INFO "is_smm:%d\n", is_smm(vcpu)); > > + > > if (vcpu->arch.smi_pending && !is_smm(vcpu)) { > > vcpu->arch.smi_pending = false; > > process_smi(vcpu); > > } > > > > Then I found that the normal output is (is_smm is 0): > > 2016-08-11T09:44:45.090078+08:00|info|kernel[-]|[1269634.151054get smi > > ioctl from qemu > > 2016-08-11T09:44:45.090097+08:00|info|kernel[-]|[1269634.151056in > > process_smi_request > > 2016-08-11T09:44:45.090114+08:00|info|kernel[-]|[1269634.151057is_smm: > > 0 > > 2016-08-11T09:44:45.090131+08:00|info|kernel[-]|[1269634.151058process > > smi 2016-08-11T09:44:45.090914+08:00|info|kernel[-]|[1269634.151575get > > smi ioctl from qemu > > 2016-08-11T09:44:45.090947+08:00|info|kernel[-]|[1269634.151578in > > process_smi_request > > 2016-08-11T09:44:45.090972+08:00|info|kernel[-]|[1269634.151579is_smm: > > 0 > > > > When problem occurs the output is (is_smm is 1): > > 2016-08-11T10:07:11.755982+08:00|info|kernel[-]|[1270981.916056get smi > > ioctl from qemu > > 2016-08-11T10:07:11.756035+08:00|info|kernel[-]|[1270981.916062in > > process_smi_request > > 2016-08-11T10:07:11.756078+08:00|info|kernel[-]|[1270981.916064is_smm: > > 1 2016-08-11T10:07:13.896977+08:00|info|kernel[-]|[1270984.058117get > > smi ioctl from qemu > > 2016-08-11T10:07:13.897063+08:00|info|kernel[-]|[1270984.058121in > > process_smi_request > > 2016-08-11T10:07:13.897091+08:00|info|kernel[-]|[1270984.058123is_smm: > > 1 > > > > So, it seems kvm cannot set HF_SMM_MASK flag correctly when we > continuously reset VM. > > Any futher suggestion? Paolo :) > > I guess a KVM_SET_VCPU_EVENTS is missing at reset time. This maybe a kvm bug of SMM supporting feature: assuming kvm SMI injection process is interrupted at the point between process_smi() and bios executing RSM. Then bios runs from the beginning again because of resetting and kvm keeps is_smm() =1. When bios writes 0xb2 to raise a SMI, kvm thinks is_smm() = 1, and will not process this request, and also will not call kvm_vcpu_reset() to clear HF_SMM_MASK flag any more. Bios will not executing RSM because of it does not get this SMI injecting from kvm. This condition cannot break until we destroy this VM. After testing 2 days, following patch can solve this problem, but obviously it is not a suitable solution: static int kvm_vcpu_ioctl_smi(struct kvm_vcpu *vcpu) { + if (is_smm(vcpu)) { + vcpu->arch.hflags &= ~HF_SMM_MASK; + vcpu->arch.smi_pending = 0; + } kvm_make_request(KVM_REQ_SMI, vcpu); return 0; } Paolo, could you post a suitable patch to solve this problem based on the information I mentioned above? > Paolo

1 0

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

SeaBIOS