SeaBIOS

seabios@seabios.org

4 participants
3801 discussions

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

12 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 12 Sep '16

12 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 30 Aug '16

30 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 30 Aug '16

30 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 25 Aug '16

25 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 21 Aug '16

21 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

[PATCH v3 0/7] tpm: Extend PCRs in all available PCR banks
by Stefan Berger 11 Aug '16

11 Aug '16

This series of patches extends the TPM2 code to extend the BIOS related PCRs 0-7 in all available banks. This prevents that these PCRs remain untouched and filled with bogus values by applications. For example, the SHA1 hash is extended into the SHA256 bank. The value that is extended into this bank is essentially a SHA1 with zero bytes used for filling it to the size of a sha256 hash. This is done for all PCR banks of the TPM2 where these PCRs are available. v2->v3: - Following Kevin's comments; would defer split-up of code in tcgbios.c to a later time v1->v2: - extended the log functions for logging the additional hashes. This added more patches to this series Regards, Stefan Stefan Berger (7): tpm: Retrieve the PCR Bank configuration tpm: Restructure tpm20_extend to use buffer and take hash as parameter tpm: Refactor tpml_digest_values_sha1 structure tpm: Extend tpm20_extend to support extending to multiple PCR banks tpm: Move tpm_log_init to a later point tpm: Adjust the TPM2 log header to show all hashes tpm: Append to TPM2 log the hashes used for PCR extension src/std/tcg.h | 86 +++++++++++-- src/tcgbios.c | 404 ++++++++++++++++++++++++++++++++++++++++++++++++++-------- 2 files changed, 421 insertions(+), 69 deletions(-) -- 2.5.5

2 13

Re: [SeaBIOS] [QUESTION]stuck in SeaBIOS and vm cannot be reset any more
by Paolo Bonzini 11 Aug '16

11 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. Paolo

1 0

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

SeaBIOS