SeaBIOS

seabios@seabios.org

3783 discussions

Use SeaBIOS as UEFI CSM
by Paul Menzel 01 Nov '18

01 Nov '18

Dear SeaBIOS folks, Colleagues from another institute have the problem, that the PC vendors started to remove the CSM (legacy BIOS) option from their UEFI firmware. A lot of organizations still use the CSM (legcacy BIOS) option to deploy their systems. I’d like to recommend SeaBIOS to them, but I only found instruction for doing that with OVMF [1]. Do you know of a how-to for UEFI firmware, which is shipped on hardware? From that iPXE should be started. Kind regards, Paul [1]: https://www.seabios.org/Build_overview#Build_as_a_UEFI_Compatibility_Suppor…

3 3

Re: [SeaBIOS] Seabios blocked at running option rom at c000:0003
by Kevin O'Connor 19 Oct '18

19 Oct '18

On Sun, Oct 14, 2018 at 03:32:22PM +0800, Acewind wrote: > Dear All, > These days I'm working on Intel IGD passthrough by qemu+vfio. > Success on i3-6100, but failed on i3-6100U. [...] > Found 2 cpu(s) max supported 2 cpu(s) > Copying PIR from 0x7ffbfca0 to 0x000f1c40 > Copying MPTABLE from 0x00006e90/7ffa8e80 to 0x000f1b10 > Copying SMBIOS entry point from 0x00006e90 to 0x000f1930 > Scan for VGA option rom > Running option rom at c000:0003 > > Now seabios stops and monitor shows no signal. > I have install win10 directly on the host and it works well. Does it means > the vga rom image is ok? What can I do for further debug? Thanks! The "Running option rom at c000:0003" indicates a video card option rom was found and SeaBIOS started executing it. The likely reason for the failure is that the video option rom itself crashed. It's difficult to debug these types of failures because it is rare to have access to the video rom code. -Kevin

2 1

Seabios blocked at running option rom at c000:0003
by Acewind 14 Oct '18

14 Oct '18

Dear All, These days I'm working on Intel IGD passthrough by qemu+vfio. Success on i3-6100, but failed on i3-6100U. The two cpus are both SkyLake arch. I have successed to passthrough IGD device to Win7/Win10 on an i3-6100 machine with Fedora 25. I use legacy mode and set x-igd-gms=1 on qemu command line. When I work on another machine of i3-6100U with the same solution. CPU: Intel(R) Core(TM) i3-6100U CPU @ 2.30GHz VGA: 00:02.0 VGA compatible controller: Intel Corporation HD Graphics 520 (rev 07) [root localhost ~]# dmesg | grep IOMMU [ 0.000000] DMAR: IOMMU enabled [ 0.067707] DMAR-IR: IOAPIC id 2 under DRHD base 0xfed91000 IOMMU 1 [root localhost ~]# cat /proc/cmdline BOOT_IMAGE=/vmlinuz-4.8.6-300.fc25.x86_64 root=/dev/mapper/fedora-root ro rd.lvm.lv=fedora/root rd.lvm.lv=fedora/swap rhgb quiet intel_iommu=on iommu=pt After virsh create command, nothing displays on the screen, there's always no signal. No other graphic and video devices, only passthrough hostdev: <hostdev mode='subsystem' type='pci' managed='yes'> <driver name='vfio'/> <source> <address domain='0x0000' bus='0x00' slot='0x02' function='0x0'/> </source> <alias name='hostdev0'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x02' function='0x0'/> </hostdev> [root localhost ~]# ps -elf | grep qemu 6 S qemu 1541 1 99 80 0 - 804613 poll_s 17:34 ? 00:04:22 /usr/bin/qemu-system-x86_64 -machine accel=kvm -name guest=cn_windows_10_enterprise_version_1703_updated_july_2017_x64_dvd_10925390,debug-threads=on -S -object secret,id=masterKey0,format=raw,file=/var/lib/libvirt/qemu/domain-2-cn_windows_10_enterp/master-key.aes -machine pc-i440fx-2.7,accel=kvm,usb=off -cpu Skylake-Client,hv_time,hv_relaxed,hv_vapic,hv_spinlocks=0x1fff -m 2048 -realtime mlock=off -smp 2,sockets=2,cores=1,threads=1 -uuid 128589da-017e-412d-b807-92de81ca7a29 -display none -no-user-config -nodefaults -chardev socket,id=charmonitor,path=/var/lib/libvirt/qemu/domain-2-cn_windows_10_enterp/monitor.sock,server,nowait -mon chardev=charmonitor,id=monitor,mode=control -rtc base=localtime,driftfix=slew -global kvm-pit.lost_tick_policy=discard -no-hpet -no-shutdown -global PIIX4_PM.disable_s3=1 -global PIIX4_PM.disable_s4=1 -boot strict=on -device ich9-usb-ehci1,id=usb,bus=pci.0,addr=0x5.0x7 -device ich9-usb-uhci1,masterbus=usb.0,firstport=0,bus=pci.0,multifunction=on,addr=0x5 -device ich9-usb-uhci2,masterbus=usb.0,firstport=2,bus=pci.0,addr=0x5.0x1 -device ich9-usb-uhci3,masterbus=usb.0,firstport=4,bus=pci.0,addr=0x5.0x2 -drive file=/home/zwj/cn_windows_10_enterprise_version_1703_updated_july_2017_x64_dvd_10925390.qcow2,format=qcow2,if=none,id=drive-ide0-0-0 -device ide-hd,bus=ide.0,unit=0,drive=drive-ide0-0-0,id=ide0-0-0,bootindex=1 -netdev tap,fd=26,id=hostnet0 -device rtl8139,netdev=hostnet0,id=net0,mac=52:54:00:86:04:cc,bus=pci.0,addr=0x3 -chardev pty,id=charserial0 -device isa-serial,chardev=charserial0,id=serial0 -device usb-tablet,id=input0,bus=usb.0,port=1 -device vfio-pci,host=00:02.0,id=hostdev0,bus=pci.0,addr=0x2 -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x4 -bios /usr/share/seabios/bios.bin -chardev file,id=seabios,path=/tmp/bios.log -device isa-debugcon,iobase=0x402,chardev=seabios -set device.hostdev0.x-igd-opregion=on -set device.hostdev0.x-igd-gms=1 -msg timestamp=on dmesg has an error: [五 10月 12 17:34:21 2018] Console: switching to colour dummy device 80x25 [五 10月 12 17:34:21 2018] vgaarb: device changed decodes: PCI:0000:00:02.0,olddecodes=io+mem,decodes=io+mem:owns=io+mem [五 10月 12 17:34:21 2018] virbr0: port 2(vnet0) entered blocking state [五 10月 12 17:34:21 2018] virbr0: port 2(vnet0) entered disabled state [五 10月 12 17:34:21 2018] device vnet0 entered promiscuous mode [五 10月 12 17:34:21 2018] virbr0: port 2(vnet0) entered blocking state [五 10月 12 17:34:21 2018] virbr0: port 2(vnet0) entered listening state [五 10月 12 17:34:22 2018] DMAR: DRHD: handling fault status reg 2 [五 10月 12 17:34:22 2018] DMAR: [DMA Write] Request device [00:02.0] fault addr 0 [fault reason 02] Present bit in context entry is clear [五 10月 12 17:34:22 2018] vfio_ecap_init: 0000:00:02.0 hiding ecap 0x1b 0x100 [五 10月 12 17:34:23 2018] virbr0: port 2(vnet0) entered learning state [五 10月 12 17:34:25 2018] virbr0: port 2(vnet0) entered forwarding state [五 10月 12 17:34:25 2018] virbr0: topology change detected, propagating Below is log of SeaBIOS, it stops at running rom: [root localhost ~]# cat /tmp/bios.log SeaBIOS (version 1.9.3-1.fc25) BUILD: gcc: (GCC) 6.1.1 20160621 (Red Hat Cross 6.1.1-2) binutils: version 2.26.1-1.fc25 RamSize: 0x80000000 [cmos] Relocating init from 0x000e4080 to 0x7ffb2320 (size 56384) Found QEMU fw_cfg QEMU fw_cfg DMA interface supported RamBlock: addr 0x0000000000000000 len 0x0000000080000000 [e820] Moving pm_base to 0x600 boot order: 1: /pci i0cf8/ide 1,1/drive 0/disk 0 2: HALT === PCI bus & bridge init === PCI: pci_bios_init_bus_rec bus = 0x0 === PCI device probing === Found 12 PCI devices (max PCI bus is 00) === PCI new allocation pass #1 === PCI: check devices === PCI new allocation pass #2 === PCI: IO: c000 - c1cf PCI: 32: 0000000080000000 - 00000000fec00000 PCI: map device bdf=00:03.0 bar 0, addr 0000c000, size 00000100 [io] PCI: map device bdf=00:02.0 bar 4, addr 0000c100, size 00000040 [io] PCI: map device bdf=00:04.0 bar 0, addr 0000c140, size 00000020 [io] PCI: map device bdf=00:05.0 bar 4, addr 0000c160, size 00000020 [io] PCI: map device bdf=00:05.1 bar 4, addr 0000c180, size 00000020 [io] PCI: map device bdf=00:05.2 bar 4, addr 0000c1a0, size 00000020 [io] PCI: map device bdf=00:01.1 bar 4, addr 0000c1c0, size 00000010 [io] PCI: map device bdf=00:02.0 bar 0, addr fd000000, size 01000000 [mem] PCI: map device bdf=00:03.0 bar 6, addr fe000000, size 00040000 [mem] PCI: map device bdf=00:02.0 bar 6, addr fe040000, size 00020000 [mem] PCI: map device bdf=00:03.0 bar 1, addr fe060000, size 00001000 [mem] PCI: map device bdf=00:05.7 bar 0, addr fe061000, size 00001000 [mem] PCI: map device bdf=00:02.0 bar 2, addr e0000000, size 10000000 [prefmem] PCI: map device bdf=00:04.0 bar 4, addr f0000000, size 00800000 [prefmem] PCI: init bdf=00:00.0 id=8086:1237 PCI: init bdf=00:01.0 id=8086:7000 PIIX3/PIIX4 init: elcr=00 0c PCI: init bdf=00:01.1 id=8086:7010 PCI: init bdf=00:01.3 id=8086:7113 Using pmtimer, ioport 0x608 PCI: init bdf=00:02.0 id=8086:1916 Intel IGD OpRegion enabled at 0x7fffe000, size 8KB, dev 00:02.0 Intel IGD BDSM enabled at 0x7d700000, size 40MB, dev 00:02.0 PCI: init bdf=00:03.0 id=10ec:8139 PCI: init bdf=00:04.0 id=1af4:1002 PCI: init bdf=00:05.0 id=8086:2934 PCI: init bdf=00:05.1 id=8086:2935 PCI: init bdf=00:05.2 id=8086:2936 PCI: init bdf=00:05.7 id=8086:293a PCI: init bdf=00:1f.0 id=8086:9d48 PCI: Using 00:02.0 for primary VGA handle_smp: apic_id=1 Found 2 cpu(s) max supported 2 cpu(s) Copying PIR from 0x7ffbfca0 to 0x000f1c40 Copying MPTABLE from 0x00006e90/7ffa8e80 to 0x000f1b10 Copying SMBIOS entry point from 0x00006e90 to 0x000f1930 Scan for VGA option rom Running option rom at c000:0003 Now seabios stops and monitor shows no signal. I have install win10 directly on the host and it works well. Does it means the vga rom image is ok? What can I do for further debug? Thanks!

1 0

release planning ...
by Gerd Hoffmann 10 Oct '18

10 Oct '18

Hi, I'm wondering whenever it makes sense to switch seabios to time-based releases, like many other projects do meanwhile. For major releases one release per year looks reasonable to me, given the low rate of changes we have. 1.11 was tagged in November 2017. So maybe target 1.12 for November 2018 ? For stable releases we could plan to create a release every one or two months. Skip in case there are no patches queued. Or stick to the current model which kind-of syncs stable releases to qemu releases (which is roughly every four months). Comments? cheers, Gerd

2 2

[PATCH v2] pretty boot menu entry for cdrom drives
by Gerd Hoffmann 05 Oct '18

05 Oct '18

Show the volume label of bootable cdroms. Signed-off-by: Gerd Hoffmann <kraxel(a)redhat.com> --- src/util.h | 1 + src/boot.c | 10 ++++++++++ src/cdrom.c | 46 ++++++++++++++++++++++++++++++++++++++++++++++ 3 files changed, 57 insertions(+) diff --git a/src/util.h b/src/util.h index 7a23b518fc..6dd080f673 100644 --- a/src/util.h +++ b/src/util.h @@ -50,6 +50,7 @@ struct disk_op_s; int cdemu_process_op(struct disk_op_s *op); void cdrom_prepboot(void); int cdrom_boot(struct drive_s *drive_g); +char *cdrom_media_info(struct drive_s *drive_g); // clock.c void clock_setup(void); diff --git a/src/boot.c b/src/boot.c index ff705fd47f..9f82f3ca0c 100644 --- a/src/boot.c +++ b/src/boot.c @@ -395,6 +395,16 @@ boot_add_hd(struct drive_s *drive, const char *desc, int prio) void boot_add_cd(struct drive_s *drive, const char *desc, int prio) { + if (GET_GLOBAL(PlatformRunningOn) & PF_QEMU) { + // We want short boot times. But on physical hardware even + // the test unit ready can take several seconds. So do media + // access on qemu only, where we know it will be fast. + char *extra = cdrom_media_info(drive); + if (extra) { + desc = znprintf(MAXDESCSIZE, "%s (%s)", desc, extra); + free(extra); + } + } bootentry_add(IPL_TYPE_CDROM, defPrio(prio, DefaultCDPrio) , (u32)drive, desc); } diff --git a/src/cdrom.c b/src/cdrom.c index 828fb3b842..577d69d812 100644 --- a/src/cdrom.c +++ b/src/cdrom.c @@ -274,3 +274,49 @@ cdrom_boot(struct drive_s *drive) return 0; } + +// check if media is present and the drive is bootable. +// in case it is return the volume label. +char* +cdrom_media_info(struct drive_s *drive) +{ + ASSERT32FLAT(); + + struct disk_op_s dop; + memset(&dop, 0, sizeof(dop)); + dop.drive_fl = drive; + + int ret = scsi_is_ready(&dop); + if (ret) + return NULL; + + // Read the Boot Record Volume Descriptor + u8 buffer[CDROM_SECTOR_SIZE]; + dop.command = CMD_READ; + dop.lba = 0x11; + dop.count = 1; + dop.buf_fl = buffer; + ret = process_op(&dop); + if (ret) + return NULL; + + // Is it bootable? + if (buffer[0]) + return NULL; + if (strcmp((char*)&buffer[1], "CD001\001EL TORITO SPECIFICATION") != 0) + return NULL; + + // Read the Primary Volume Descriptor + dop.command = CMD_READ; + dop.lba = 0x10; + dop.count = 1; + dop.buf_fl = buffer; + ret = process_op(&dop); + if (ret) + return NULL; + + // Read volume id, trim trailing spaces + char *volume = znprintf(30, "%s", buffer + 40); + nullTrailingSpace(volume); + return volume; +} -- 2.9.3

2 2

Re: [SeaBIOS] [RFC v3] pciinit: setup mcfg for pxb-pcie to support multiple pci domains
by Gerd Hoffmann 01 Oct '18

01 Oct '18

Hi, > > I'm curious; what does tape backup have to do with the number of PCI > > slots/busses? > > I'm not very clear about how tape works in qemu, but the problem is pcie > devices under q35. The pcie topology requires one device per bus, therefore > the 256 bus might not be enough if we have many pcie devices. Note that you can have multifunction pcie devices. so you can have up to 8 per pcie slot. Which allows close to 2000 devices. Limitation: They are not individually hotpluggable. cheers, Gerd

1 0

Re: [SeaBIOS] [RFC v3] pciinit: setup mcfg for pxb-pcie to support multiple pci domains
by Kevin O'Connor 30 Sep '18

30 Sep '18

On Thu, Sep 27, 2018 at 11:05:13PM +0800, Zihan Yang wrote: > Laszlo Ersek <lersek(a)redhat.com> 于2018年9月26日周三上午1:17写道： > > First, I fail to see the use case where ~256 PCI bus numbers aren't > > enough. If I strain myself, perhaps I can imagine using ~200 PCIe root > > ports on Q35 (each of which requires a separate bus number), so that we > > can independently hot-plug 200 devices then. And that's supposedly not > > enough, because we want... 300? 400? A thousand? Doesn't sound realistic > > to me. (This is not meant to be a strawman argument, I really have no > > idea what the feature would be useful for.) > > It might not be very intuitive, but it indeed exists. The very > beginning discussion > about 4 months ago has mentioned a possible use case, and I paste it here [...] > Things might change in the future if we can figure out a better solution, and I > hope we can have an easier and more elegant solution in OVMF. But now > we are just trying to give a possible solution as a poc. Thanks. I wasn't aware this was a proof of concept. (Nor have I been following the discussions on the qemu list.) I don't think it makes sense to merge this into the main SeaBIOS repository. The QEMU/firmware interface is already complex and I don't think we should complicate it further without a more concrete use case. In particular, it seems unclear if 256 buses is enough or if 1024 buses is too little. -Kevin

2 1

Re: [SeaBIOS] [RFC v3] pciinit: setup mcfg for pxb-pcie to support multiple pci domains
by Dr. David Alan Gilbert 29 Sep '18

29 Sep '18

* Zihan Yang (whois.zihan.yang(a)gmail.com) wrote: > HI Laszlo > Laszlo Ersek <lersek(a)redhat.com> 于2018年9月26日周三上午1:17写道： > > > > On 09/25/18 17:38, Kevin O'Connor wrote: > > > On Mon, Sep 17, 2018 at 11:02:59PM +0800, Zihan Yang wrote: > > >> To support multiple pci domains of pxb-pcie device in qemu, we need to setup > > >> mcfg range in seabios. We use [0x80000000, 0xb0000000) to hold new domain mcfg > > >> table for now, and we need to retrieve the desired mcfg size of each pxb-pcie > > >> from a hidden bar because they may not need the whole 256 busses, which also > > >> enables us to support more domains within a limited range (768MB) > > > > > > At a highlevel, this looks okay to me. I'd like to see additional > > > reviews from others more familiar with the QEMU PCI code, though. > > > > > > Is the plan to do the same thing for OVMF? > > > > I remain entirely unconvinced that this feature is useful. (I've stated > > so before.) > > > > I believe the latest QEMU RFC posting (v5) is here: > > > > [Qemu-devel] [RFC v5 0/6] pci_expander_brdige: support separate pci > > domain for pxb-pcie > > > > http://mid.mail-archive.com/1537196258-12581-1-git-send-email-whois.zihan.y… > > > > First, I fail to see the use case where ~256 PCI bus numbers aren't > > enough. If I strain myself, perhaps I can imagine using ~200 PCIe root > > ports on Q35 (each of which requires a separate bus number), so that we > > can independently hot-plug 200 devices then. And that's supposedly not > > enough, because we want... 300? 400? A thousand? Doesn't sound realistic > > to me. (This is not meant to be a strawman argument, I really have no > > idea what the feature would be useful for.) > > It might not be very intuitive, but it indeed exists. The very > beginning discussion > about 4 months ago has mentioned a possible use case, and I paste it here > > - We have Ray from Intel trying to use 1000 virtio-net devices why that many? > - We may have a VM managing some backups (tapes), we may have a lot of these. I'm curious; what does tape backup have to do with the number of PCI slots/busses? Dave > - We may want indeed to create a nested solution as Michael mentioned. > > The thread can be found in > https://lists.gnu.org/archive/html/qemu-devel/2018-05/msg04667.html > > Also, a later post from a person in Dell stated in the list that he would need > this feature for Intel VMD In Dell EMC? I have no idea about the details, > but since they went here for help, I guess they do can benefit from it somehow. > > > Second, the v5 RFC doesn't actually address the alleged bus number > > shortage. IIUC, it supports a low number of ECAM ranges under 4GB, but > > those are (individually) limited in the bus number ranges they can > > accommodate (due to 32-bit address space shortage). So more or less the > > current approach just fragments the bus number space we already have, to > > multiple domains. > > > > Third, should a subsequent iteration of the QEMU series put those extra > > ECAMs above 4GB, with the intent to leave the enumeration of those > > hierarchies to the "guest OS", it would present an incredible > > implementation mess for OVMF. If people gained the ability to attach > > storage or network to those domains, on the QEMU command line, they > > would expect to boot off of them, using UEFI. Then OVMF would have to > > make sure the controllers could be bound by their respective UEFI > > drivers. That in turn would require functional config space access > > (ECAM) at semi-random 64-bit addresses. > > I'm not familiar with OVMF, so I'm afraid I don't know how to make it easier > for OVMF, the division of 64bit space in OVMF is out of my purpose. There > is no plan to implement it in OVMF for now, we just want to make the > seabios/qemu patch a proof of concept. > > As for the seabios, it access devices through port 0xcf8/0xcfc, which is binded > to q35 host in qemu. If we want to change the mmconfig size of pxb-pcie > (instead of using whole 256MB), we must know its desired size, which is passed > as a hidden bar. Unfortunately the configuration space of pxb-pcie device > cannot be accessed with 0xcf8/0xcfc because they are in different host bridge. > At this time the ECAM is not configured yet, so no able to use MMIO too. > In previous version, I tried to bind pxb host to other ports in qemu, so that we > can use port io to access the config space of pxb-pcie, but it seems a > little dirty, > > Another issue is how seabios initialize things. It will first do pci_setup when > things like RSDP is not loaded. It is inconvenient to retrieve MCFG table and > other information, so we cannot infer the mmconfig addr and size from MCFG > table in seabios. > > Therefore we fall back to an alternative that we support 4x of devices as the > first step, and let the guest os do the initialization. The inability to boot > from devices in another domain is indeed an issue, and we don't have very > good solution to it yet. > > Things might change in the future if we can figure out a better solution, and I > hope we can have an easier and more elegant solution in OVMF. But now > we are just trying to give a possible solution as a poc. > > Thanks > Zihan > > _______________________________________________ > SeaBIOS mailing list > SeaBIOS(a)seabios.org > https://mail.coreboot.org/mailman/listinfo/seabios -- Dr. David Alan Gilbert / dgilbert(a)redhat.com / Manchester, UK

2 1

[PATCH] pretty boot menu entry for cdrom drives
by Gerd Hoffmann 28 Sep '18

28 Sep '18

Signed-off-by: Gerd Hoffmann <kraxel(a)redhat.com> --- src/util.h | 1 + src/boot.c | 7 +++++++ src/cdrom.c | 51 +++++++++++++++++++++++++++++++++++++++++++++++++++ 3 files changed, 59 insertions(+) diff --git a/src/util.h b/src/util.h index 7a23b518fc..6dd080f673 100644 --- a/src/util.h +++ b/src/util.h @@ -50,6 +50,7 @@ struct disk_op_s; int cdemu_process_op(struct disk_op_s *op); void cdrom_prepboot(void); int cdrom_boot(struct drive_s *drive_g); +char *cdrom_media_info(struct drive_s *drive_g); // clock.c void clock_setup(void); diff --git a/src/boot.c b/src/boot.c index ff705fd47f..80bcc13535 100644 --- a/src/boot.c +++ b/src/boot.c @@ -395,6 +395,13 @@ boot_add_hd(struct drive_s *drive, const char *desc, int prio) void boot_add_cd(struct drive_s *drive, const char *desc, int prio) { + if (GET_GLOBAL(PlatformRunningOn) & PF_QEMU) { + // We want short boot times. But on physical hardware even + // the test unit ready can take several seconds. So do media + // access on qemu only, where we know it will be fast. + char *extra = cdrom_media_info(drive); + desc = znprintf(MAXDESCSIZE, "%s (%s)", desc, extra); + } bootentry_add(IPL_TYPE_CDROM, defPrio(prio, DefaultCDPrio) , (u32)drive, desc); } diff --git a/src/cdrom.c b/src/cdrom.c index 828fb3b842..b4c36622ae 100644 --- a/src/cdrom.c +++ b/src/cdrom.c @@ -274,3 +274,54 @@ cdrom_boot(struct drive_s *drive) return 0; } + +// go figure some cdrom information, for a pretty boot menu entry. +char* +cdrom_media_info(struct drive_s *drive) +{ + ASSERT32FLAT(); + + struct disk_op_s dop; + memset(&dop, 0, sizeof(dop)); + dop.drive_fl = drive; + + int ret = scsi_is_ready(&dop); + if (ret) + return "empty"; + + // Read the Boot Record Volume Descriptor + u8 buffer[CDROM_SECTOR_SIZE]; + dop.command = CMD_READ; + dop.lba = 0x11; + dop.count = 1; + dop.buf_fl = buffer; + ret = process_op(&dop); + if (ret) + return "read error"; + + // Is it bootable? + if (buffer[0]) + return "not bootable"; + if (strcmp((char*)&buffer[1], "CD001\001EL TORITO SPECIFICATION") != 0) + return "not bootable"; + + // Read the Primary Volume Descriptor + dop.command = CMD_READ; + dop.lba = 0x10; + dop.count = 1; + dop.buf_fl = buffer; + ret = process_op(&dop); + if (ret) + return "read error"; + + // Read volume id, trim trailing spaces + char *volume = znprintf(30, "%s", buffer + 40); + char *h = volume + strlen(volume); + while (h > volume) { + h--; + if (*h != ' ') + break; + *h = 0; + } + return volume; +} -- 2.9.3

3 4

[RFC v3] Support multiple pci domain for pxb-pcie of qemu
by Zihan Yang 28 Sep '18

28 Sep '18

The qemu part of this patch can be found in https://lists.gnu.org/archive/html/qemu-devel/2018-09/msg01988.html pxb-pcie device in qemu uses only one pci domain(0) so far, which means there are at most 256 busses. However, pcie topology requires one bus per device, which will use up the busses soon if there are more pcie devices. To solve the problem, QEMU can put the pxb-pcie in separate pci domain so we can get more devices. As QEMU relies on seabios to allocate space for its mcfg table, we must modify the seabios to configure mcfg_base and mcfg_size for qemu. Since pxb-pcie may only uses a subset of all 256 busses in a domain, we let qemu pass its desired mcfg_size as a hidden bar, seabios just decides the mcfg_base for it. Compared with previous design, mmconfig is not put above 4g anymore, but inside [0x80000000, 0xb0000000), and leaves the major part of configuration to guest OS, which makes the whole part of code much simpler. Changelog: v3 <- v2 - Refactor design so that seabios only does minimal mcfg configure, and leaves everything else to guest os. This makes the code much simpler. - Does not put mcfg over 4g anymore, but inside [0x80000000, 0xb0000000) Over 4g placement can be expected in future version. 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 (1): pciinit: setup mcfg for pxb-pcie to support multiple pci domains src/fw/dev-q35.h | 7 +++++++ src/fw/pciinit.c | 32 ++++++++++++++++++++++++++++++++ src/hw/pci_ids.h | 1 + 3 files changed, 40 insertions(+) -- 2.7.4

4 7

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

SeaBIOS