August 2018 - SeaBIOS - mail.coreboot.org

Re: [SeaBIOS] [coreboot] Upgrade the 12 years old LZMA libraries - should we do it?
by Carl-Daniel Hailfinger Jan. 29, 2019

Jan. 29, 2019

Hi Ivan, On 03.04.2018 20:03, Ivan Ivanov wrote: > I have noticed that both coreboot and seabios are using the very old > versions of LZMA SDK. True. I introduced the lzma code in coreboot (back when it was called LinuxBIOS) when we were working on OLPC XO-1 support. > If we will upgrade our LZMA libraries from the > outdated-by-12-years 4.42 to the current version 18.04 , speed and > compression ratio should improve and maybe a few bugs will be fixed. Do you have any numbers for this? An improved compression ratio and improved speed would be nice indeed, but how does the size of the decompression code change? If the decompression code grows more than the size reduction from better compression, it would be a net loss. A significantly reduced decompression speed would also be a problem. Decompression speed would have to be measured both for stream decompression (i.e. the decompressor gets the compressed data in single-byte or multibyte chunks) as well as full-size decompression (i.e. the decompressor can access all compressed data at once). We also have to make sure that stream decompression still works after the change. > Do you think it should be done, or you are OK with using such an > outdated version? A size benefit for the resulting image is a good reason to switch. Regards, Carl-Daniel

3 2

[PATCH v3 0/3] pci: resource reserve capability found
by Jing Liu Sept. 14, 2018

Sept. 14, 2018

This patch serial is about QEMU resource reserve capability finding in firmware. Firstly, this fixes a logic bug. When the capability is truncated, return zero instead of the truncated offset. Secondly, this modified the debug messages when the capability is not found and when the vendor ID or device Id doesn't match REDHAT special ones. Last, this enables the firmware recongizing the REDHAT PCI BRIDGE device ID, and changes the debug level to 3 when it is non-qemu bridge. Change Log: v2 -> v1 * Add two patches for fixing small bugs v3 -> v2 * Change the debug level Jing Liu (3): pci: fix the return value for truncated capability pci: clean up the debug message for pci capability found pci: recognize RH PCI legacy bridge resource reservation capability src/fw/pciinit.c | 45 ++++++++++++++++++++++++++++----------------- src/hw/pci_ids.h | 1 + 2 files changed, 29 insertions(+), 17 deletions(-) -- 1.8.3.1

6 12

Error Data Hob
by zahra rahimkhani Aug. 29, 2018

Aug. 29, 2018

Hello Friends , I compiled Coreboot 4.5 and seabios for Minnow board max and see this message in consol. "Memory Configure Data Hob is not present. Not updating MRC data in flash." what is Data Hob? what is MRC data؟ Cold you help me how to solve it? Best wishes , Zhara

1 0

Backport request for 8c3f57ea12
by Wei Liu Aug. 29, 2018

Aug. 29, 2018

Hello I notice 1.11.2 was only released a few weeks ago so it is probably too early for another release, but can maintainers at least consider backporting 8c3f57ea12 to 1.11-stable branch? Thanks, Wei.

2 2

Re: [SeaBIOS] Error Data Hob
by Paul Menzel Aug. 29, 2018

Aug. 29, 2018

Dear Zhara, On 08/29/18 19:19, zahra rahimkhani wrote: > I compiled Coreboot 4.5 and seabios for Minnow board max and see this > message in consol. > > "Memory Configure Data Hob is not present. > Not updating MRC data in flash." > > what is Data Hob? > what is MRC data؟ > Could you help me how to solve it? Unfortunately, you wrote to the wrong list. SeaBIOS is the payload, and the messages you quoted are from coreboot. Please contact the coreboot mailing list. I advise, to test the latest version 4.8 before contacting the coreboot project though. Kind regards, Paul PS: In the future, always attach the whole log.

1 0

Re: [SeaBIOS] [RFC v2 0/3] Support multiple pci domains in pci_device
by Marcel Apfelbaum Aug. 28, 2018

Aug. 28, 2018

Hi Gerd On 08/28/2018 07:12 AM, Zihan Yang wrote: > Gerd Hoffmann <kraxel(a)redhat.com> 于2018年8月27日周一上午7:04写道： >> Hi, >> >>>> However, QEMU only binds port 0xcf8 and 0xcfc to >>>> bus pcie.0. To avoid bus confliction, we should use other port pairs for >>>> busses under new domains. >>> I would skip support for IO based configuration and use only MMCONFIG >>> for extra root buses. >>> >>> The question remains: how do we assign MMCONFIG space for >>> each PCI domain. Thanks for your comments! >> Allocation-wise it would be easiest to place them above 4G. Right after >> memory, or after etc/reserved-memory-end (if that fw_cfg file is >> present), where the 64bit pci bars would have been placed. Move the pci >> bars up in address space to make room. >> >> Only problem is that seabios wouldn't be able to access mmconfig then. >> >> Placing them below 4G would work at least for a few pci domains. q35 >> mmconfig bar is placed at 0xb0000000 -> 0xbfffffff, basically for >> historical reasons. Old qemu versions had 2.75G low memory on q35 (up >> to 0xafffffff), and I think old machine types still have that for live >> migration compatibility reasons. Modern qemu uses 2G only, to make >> gigabyte alignment work. >> >> 32bit pci bars are placed above 0xc0000000. The address space from 2G >> to 2.75G (0x8000000 -> 0xafffffff) is unused on new machine types. >> Enough room for three additional mmconfig bars (full size), so four >> pci domains total if you add the q35 one. > Maybe we can support 4 domains first before we come up > with a better solution. But I'm not sure if four domains are > enough for those who want too many devices? (Adding Michael) Since we will not use all 256 buses of an extra PCI domain, I think this space will allow us to support more PCI domains. How will the flow look like ? 1. QEMU passes to SeaBIOS information of how many extra PCI domains needs, and how many buses per domain. How it will pass this info? A vendor specific capability, some PCI registers or modifying extra-pci-roots fw_cfg file? 2. SeaBIOS assigns the address for each PCI Domain and returns the information to QEMU. How it will do that? Some pxb-pcie registers? Or do we model the MMCFG like a PCI BAR? 3. Once QEMU gets the MMCFG addresses, it can answer to mmio configuration cycles. 4. SeaBIOS queries all PCI domains devices, computes and assigns IO/MEM resources (for PCI domains > 0 it will use MMCFG to configure the PCI devices) 5. QEMU uses the IO/MEM information to create the CRS for each extra PCI host bridge. 6. SeaBIOS gets the ACPI tables from QEMU and passes them to the guest OS. Thanks, Marcel >> cheers, >> Gerd >>

4 7

Fwd: [RFC v2 0/3] Support multiple pci domains in pci_device
by Zihan Yang Aug. 28, 2018

Aug. 28, 2018

CCed to the wrong mailing list... resend here ---------- Forwarded message --------- From: Zihan Yang <whois.zihan.yang(a)gmail.com> Date: 2018年8月28日周二上午4:12 Subject: Re: [SeaBIOS] [RFC v2 0/3] Support multiple pci domains in pci_device To: Gerd Hoffmann <kraxel(a)redhat.com> Cc: <qemu-devel(a)nongnu.org>, Marcel Apfelbaum <marcel.apfelbaum(a)gmail.com> Gerd Hoffmann <kraxel(a)redhat.com> 于2018年8月27日周一上午7:04写道： > > Hi, > > > > However, QEMU only binds port 0xcf8 and 0xcfc to > > > bus pcie.0. To avoid bus confliction, we should use other port pairs for > > > busses under new domains. > > > > I would skip support for IO based configuration and use only MMCONFIG > > for extra root buses. > > > > The question remains: how do we assign MMCONFIG space for > > each PCI domain. > > Allocation-wise it would be easiest to place them above 4G. Right after > memory, or after etc/reserved-memory-end (if that fw_cfg file is > present), where the 64bit pci bars would have been placed. Move the pci > bars up in address space to make room. > > Only problem is that seabios wouldn't be able to access mmconfig then. > > Placing them below 4G would work at least for a few pci domains. q35 > mmconfig bar is placed at 0xb0000000 -> 0xbfffffff, basically for > historical reasons. Old qemu versions had 2.75G low memory on q35 (up > to 0xafffffff), and I think old machine types still have that for live > migration compatibility reasons. Modern qemu uses 2G only, to make > gigabyte alignment work. > > 32bit pci bars are placed above 0xc0000000. The address space from 2G > to 2.75G (0x8000000 -> 0xafffffff) is unused on new machine types. > Enough room for three additional mmconfig bars (full size), so four > pci domains total if you add the q35 one. Maybe we can support 4 domains first before we come up with a better solution. But I'm not sure if four domains are enough for those who want too many devices? > cheers, > Gerd >

1 0

Re: [SeaBIOS] vTPM 2.0 is recognized as vTPM 1.2 on the Win 10 virtual machine with seabios
by 汤福 Aug. 28, 2018

Aug. 28, 2018

Excuse me, is there some case of successful attempts on Windows 10? Could you provide me some technical docs? Thanks! > -----原始邮件----- > 发件人: "Marc-André Lureau" <marcandre.lureau(a)gmail.com> > 发送时间: 2018-08-23 16:37:36 (星期四) > 收件人: tangfu(a)gohighsec.com > 抄送: "Kevin O'Connor" <kevin(a)koconnor.net>, seabios(a)seabios.org > 主题: Re: [SeaBIOS] vTPM 2.0 is recognized as vTPM 1.2 on the Win 10 virtual machine with seabios > > Hi > > On Thu, Aug 23, 2018 at 9:29 AM 汤福 <tangfu(a)gohighsec.com> wrote: > > > > Hi， > > I am sorry, I bothered you. Still vTPM 2.0 for win 10 problem， I downloaded the latest qemu source from git, the version is V3.0.50. I think this is the latest code of qemu upstream. I also downloaded seabios upstream and bulid it with tpm2 support. Unfortunately, I tried both passthrough and emulator, and I didn’t get the expected results. > > > > For emulator， I did it like this： > > #mkdir /tmp/mytpm2/ > > #chown tss:root /tmp/mytpm2 > > #swtpm_setup --tpmstate /tmp/mytpm2 --create-ek-cert --create-platform-cert --allow-signing --tpm2 > > #swtpm socket --tpmstate dir=/tmp/mytpm2 --ctrl type=unixio,path=/tmp/mytpm2/swtpm-sock --log level=20 --tpm2 > > > > No errors occurred, suggesting that the certificate was also generated successfully.Then I created a blank img file named win10.img，and install win10 virtual machine as follows： > > #qemu-system-x86_64 -display sdl -enable-kvm -cdrom win10.iso -serial stdio -m 2048 -boot d -bios bios.bin -boot menu=on -chardev socket,id=chrtpm,path=/tmp/mytpm2/swtpm-sock -tpmdev emulator,id=tpm0,chardev=chrtpm -device tpm-crb,tpmdev=tpm0 win10-ovmf.img > > Enter the system when the system is successfully installed，I found that the TPM 2.0 device was not found in the System Device Manager. If I replace -device tpm-crb with -device tpm-tis and reboot the system，The TPM device can be found in the device manager.But the vTPM 2.0 is recognized as vTPM 1.2. > > > > I also tried passthrough mode， The result is the same as emulator. So, what could be the problem? > > > > Try with OVMF. According to some technical docs, it seems Windows > requires UEFI & CRB for TPM 2. That's also what testing suggestsTry. > We are able to pass most WLK TPM tests with this setup. > > > > > > > > -----原始邮件----- > > > 发件人: "Kevin O'Connor" <kevin(a)koconnor.net> > > > 发送时间: 2018-08-21 12:08:59 (星期二) > > > 收件人: "汤福" <tangfu(a)gohighsec.com> > > > 抄送: seabios(a)seabios.org > > > 主题: Re: [SeaBIOS] vTPM 2.0 is recognized as vTPM 1.2 on the Win 10 virtual machine with seabios > > > > > > On Mon, Aug 13, 2018 at 04:45:43PM +0800, 汤福 wrote: > > > > Hi, > > > > > > > > I want to use the vTPM in a qemu Windows image. Unfortunately, it didn't work. > > > > First, the equipment: > > > > TPM 2.0 hardware > > > > CentOS 7.2 > > > > Qemu v2.10.2 > > > > SeaBIOS 1.11.0 > > > > libtpm and so on > > > > > > If you retry with the latest SeaBIOS code from the master branch, does > > > the problem still exist? > > > > > > See: > > > https://mail.coreboot.org/pipermail/seabios/2018-August/012384.html > > > > > > -Kevin > > _______________________________________________ > > SeaBIOS mailing list > > SeaBIOS(a)seabios.org > > https://mail.coreboot.org/mailman/listinfo/seabios > > > > -- > Marc-André Lureau

1 0

[RFC v2 0/3] Support multiple pci domains in pci_device
by Zihan Yang Aug. 27, 2018

Aug. 27, 2018

Currently seabios assumes there is only one pci domain(0), and almost everything operates on pci domain 0 by default. This patch aims to add multiple pci domain support for pci_device, while reserve the original API for compatibility. The reason to get seabios involved is that the pxb-pcie host bus created in QEMU is now in a different PCI domain, and its bus number would start from 0 instead of bus_nr. Actually bus_nr should not be used when in another non-zero domain. However, QEMU only binds port 0xcf8 and 0xcfc to bus pcie.0. To avoid bus confliction, we should use other port pairs for busses under new domains. Current issues: * when trying to read config space of pcie_pci_bridge, it actually reads out the result of mch. I'm working on this weird behavior. Changelog: v2 <- v1: - Fix bugs in filtering domains when traversing pci devices - Reformat some hardcoded codes, such as probing the pci device in pci_setup Zihan Yang (3): fw/pciinit: Recognize pxb-pcie-dev device pci_device: Add pci domain support pci: filter undesired domain when traversing pci src/fw/coreboot.c | 2 +- src/fw/csm.c | 2 +- src/fw/mptable.c | 1 + src/fw/paravirt.c | 3 +- src/fw/pciinit.c | 276 ++++++++++++++++++++++++++++++--------------------- src/hw/ahci.c | 1 + src/hw/ata.c | 1 + src/hw/esp-scsi.c | 1 + src/hw/lsi-scsi.c | 1 + src/hw/megasas.c | 1 + src/hw/mpt-scsi.c | 1 + src/hw/nvme.c | 1 + src/hw/pci.c | 69 +++++++------ src/hw/pci.h | 42 +++++--- src/hw/pci_ids.h | 6 +- src/hw/pcidevice.c | 11 +- src/hw/pcidevice.h | 8 +- src/hw/pvscsi.c | 1 + src/hw/sdcard.c | 1 + src/hw/usb-ehci.c | 1 + src/hw/usb-ohci.c | 1 + src/hw/usb-uhci.c | 1 + src/hw/usb-xhci.c | 1 + src/hw/virtio-blk.c | 1 + src/hw/virtio-scsi.c | 1 + src/optionroms.c | 3 + 26 files changed, 268 insertions(+), 170 deletions(-) -- 2.7.4

3 10

[PATCH v2 0/3] pci: resource reserve capability found
by Jing Liu Aug. 25, 2018

Aug. 25, 2018

This patch serial is about QEMU resource reserve capability finding in firmware. Firstly, this fixes a logic bug. When the capability is truncated, return zero instead of the truncated offset. Secondly, this modified the debug messages when the capability is not found and when the vendor ID or device Id doesn't match REDHAT special ones. Last, this enables the firmware recongizing the REDHAT PCI BRIDGE device ID, so that QEMU can also reserve PCI bridge resource capability. Change Log: v2 -> v1 * Add two patches for fixing small bugs Jing Liu (3): pci: fix the return value for truncated capability pci: clean up the debug message for pci capability found pci: recognize RH PCI legacy bridge resource reservation capability src/fw/pciinit.c | 45 ++++++++++++++++++++++++++++----------------- src/hw/pci_ids.h | 1 + 2 files changed, 29 insertions(+), 17 deletions(-) -- 1.8.3.1

6 24