SeaBIOS September 2018

seabios@seabios.org

11 participants
14 discussions

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

29 Jan '19

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 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 Kevin O'Connor 29 Sep '18

29 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 27 Sep '18

27 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 27 Sep '18

27 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

Re: [SeaBIOS] [PATCH] virtio-blk/scsi: enable multi-queues support when starting device
by Laszlo Ersek 26 Sep '18

26 Sep '18

On 09/26/18 10:16, Liu, Changpeng wrote: > I posted the patch again, because I didn't get any response since several months ago... :). Indeed, you didn't receive any comments under that (July) posting, regrettably: http://mid.mail-archive.com/1531201226-4099-1-git-send-email-changpeng.liu@… However, prior to that, the topic had been discussed several times. QEMU commit fb20fbb76 is correct, and the idea behind the present patch is wrong. Obviously I'm not a SeaBIOS maintainer, so take my opinion for what it's worth. However, I will definitely not accept a similar patch for OVMF -- it was tried, and I rejected it: https://lists.01.org/pipermail/edk2-devel/2017-December/019131.html (In fact, although the author of the OVMF posting and the author of the QEMU patch were different persons, and it's also unclear whether they worked for the same organization, I suspect that the QEMU patch was actually the direct result of the OVMF discussion.) >> -----Original Message----- >> From: Liu, Changpeng >> Sent: Wednesday, September 26, 2018 4:24 PM >> To: seabios(a)seabios.org >> Cc: stefanha(a)redhat.com; Liu, Changpeng <changpeng.liu(a)intel.com>; Harris, >> James R <james.r.harris(a)intel.com>; Zedlewski, Piotr >> <piotr.zedlewski(a)intel.com>; marcandre.lureau(a)redhat.com >> Subject: [PATCH] virtio-blk/scsi: enable multi-queues support when starting >> device >> >> QEMU will not start all the queues since commit fb20fbb76 >> "vhost: avoid to start/stop virtqueue which is not read", >> because seabios only use one queue when starting, this will >> not work for some vhost slave targets which expect the exact >> number of queues defined in virtio-pci configuration space, This expectation that you spell out in the commit message is what's wrong, in those "vhost slave targets". Thanks Laszlo >> while here, we also enable those queues in the BIOS phase. >> >> Signed-off-by: Changpeng Liu <changpeng.liu(a)intel.com> >> --- >> src/hw/virtio-blk.c | 26 +++++++++++++++++++------- >> src/hw/virtio-ring.h | 1 + >> src/hw/virtio-scsi.c | 28 +++++++++++++++++++--------- >> 3 files changed, 39 insertions(+), 16 deletions(-) >> >> diff --git a/src/hw/virtio-blk.c b/src/hw/virtio-blk.c >> index 88d7e54..79638ec 100644 >> --- a/src/hw/virtio-blk.c >> +++ b/src/hw/virtio-blk.c >> @@ -25,7 +25,7 @@ >> >> struct virtiodrive_s { >> struct drive_s drive; >> - struct vring_virtqueue *vq; >> + struct vring_virtqueue *vq[MAX_NUM_QUEUES]; >> struct vp_device vp; >> }; >> >> @@ -34,7 +34,7 @@ virtio_blk_op(struct disk_op_s *op, int write) >> { >> struct virtiodrive_s *vdrive = >> container_of(op->drive_fl, struct virtiodrive_s, drive); >> - struct vring_virtqueue *vq = vdrive->vq; >> + struct vring_virtqueue *vq = vdrive->vq[0]; >> struct virtio_blk_outhdr hdr = { >> .type = write ? VIRTIO_BLK_T_OUT : VIRTIO_BLK_T_IN, >> .ioprio = 0, >> @@ -96,6 +96,7 @@ virtio_blk_process_op(struct disk_op_s *op) >> static void >> init_virtio_blk(void *data) >> { >> + u32 i, num_queues = 1; >> struct pci_device *pci = data; >> u8 status = VIRTIO_CONFIG_S_ACKNOWLEDGE | VIRTIO_CONFIG_S_DRIVER; >> dprintf(1, "found virtio-blk at %pP\n", pci); >> @@ -109,10 +110,6 @@ init_virtio_blk(void *data) >> vdrive->drive.cntl_id = pci->bdf; >> >> vp_init_simple(&vdrive->vp, pci); >> - if (vp_find_vq(&vdrive->vp, 0, &vdrive->vq) < 0 ) { >> - dprintf(1, "fail to find vq for virtio-blk %pP\n", pci); >> - goto fail; >> - } >> >> if (vdrive->vp.use_modern) { >> struct vp_device *vp = &vdrive->vp; >> @@ -156,6 +153,11 @@ init_virtio_blk(void *data) >> vp_read(&vp->device, struct virtio_blk_config, heads); >> vdrive->drive.pchs.sector = >> vp_read(&vp->device, struct virtio_blk_config, sectors); >> + >> + num_queues = vp_read(&vp->common, virtio_pci_common_cfg, >> num_queues); >> + if (num_queues < 1 || num_queues > MAX_NUM_QUEUES) { >> + num_queues = 1; >> + } >> } else { >> struct virtio_blk_config cfg; >> vp_get_legacy(&vdrive->vp, 0, &cfg, sizeof(cfg)); >> @@ -178,6 +180,13 @@ init_virtio_blk(void *data) >> vdrive->drive.pchs.sector = cfg.sectors; >> } >> >> + for (i = 0; i < num_queues; i++) { >> + if (vp_find_vq(&vdrive->vp, i, &vdrive->vq[i]) < 0 ) { >> + dprintf(1, "fail to find vq %u for virtio-blk %pP\n", i, pci); >> + goto fail_vq; >> + } >> + } >> + >> char *desc = znprintf(MAXDESCSIZE, "Virtio disk PCI:%pP", pci); >> boot_add_hd(&vdrive->drive, desc, bootprio_find_pci_device(pci)); >> >> @@ -185,9 +194,12 @@ init_virtio_blk(void *data) >> vp_set_status(&vdrive->vp, status); >> return; >> >> +fail_vq: >> + for (i = 0; i < num_queues; i++) { >> + free(vdrive->vq[i]); >> + } >> fail: >> vp_reset(&vdrive->vp); >> - free(vdrive->vq); >> free(vdrive); >> } >> >> diff --git a/src/hw/virtio-ring.h b/src/hw/virtio-ring.h >> index 8604a01..3c8a2d1 100644 >> --- a/src/hw/virtio-ring.h >> +++ b/src/hw/virtio-ring.h >> @@ -21,6 +21,7 @@ >> #define VIRTIO_F_IOMMU_PLATFORM 33 >> >> #define MAX_QUEUE_NUM (128) >> +#define MAX_NUM_QUEUES (128) >> >> #define VRING_DESC_F_NEXT 1 >> #define VRING_DESC_F_WRITE 2 >> diff --git a/src/hw/virtio-scsi.c b/src/hw/virtio-scsi.c >> index a87cad8..d08643f 100644 >> --- a/src/hw/virtio-scsi.c >> +++ b/src/hw/virtio-scsi.c >> @@ -148,9 +148,10 @@ virtio_scsi_scan_target(struct pci_device *pci, struct >> vp_device *vp, >> static void >> init_virtio_scsi(void *data) >> { >> + u32 i, num_queues = 3; >> struct pci_device *pci = data; >> dprintf(1, "found virtio-scsi at %pP\n", pci); >> - struct vring_virtqueue *vq = NULL; >> + struct vring_virtqueue *vq[MAX_NUM_QUEUES]; >> struct vp_device *vp = malloc_high(sizeof(*vp)); >> if (!vp) { >> warn_noalloc(); >> @@ -175,29 +176,38 @@ init_virtio_scsi(void *data) >> dprintf(1, "device didn't accept features: %pP\n", pci); >> goto fail; >> } >> + >> + num_queues = vp_read(&vp->common, virtio_pci_common_cfg, >> num_queues); >> + if (num_queues < 3 || num_queues > MAX_NUM_QUEUES) { >> + num_queues = 3; >> + } >> } >> >> - if (vp_find_vq(vp, 2, &vq) < 0 ) { >> - dprintf(1, "fail to find vq for virtio-scsi %pP\n", pci); >> - goto fail; >> + for (i = 0; i < num_queues; i++) { >> + if (vp_find_vq(vp, i, &vq[i]) < 0 ) { >> + dprintf(1, "fail to find vq %u for virtio-scsi %pP\n", i, pci); >> + goto fail; >> + } >> } >> >> status |= VIRTIO_CONFIG_S_DRIVER_OK; >> vp_set_status(vp, status); >> >> - int i, tot; >> + int tot; >> for (tot = 0, i = 0; i < 256; i++) >> - tot += virtio_scsi_scan_target(pci, vp, vq, i); >> + tot += virtio_scsi_scan_target(pci, vp, vq[2], i); >> >> if (!tot) >> - goto fail; >> + goto fail_vq; >> >> return; >> - >> +fail_vq: >> + for (i = 0; i < num_queues; i++) { >> + free(vq[i]); >> + } >> fail: >> vp_reset(vp); >> free(vp); >> - free(vq); >> } >> >> void >> -- >> 1.9.3 > > > _______________________________________________ > SeaBIOS mailing list > SeaBIOS(a)seabios.org > https://mail.coreboot.org/mailman/listinfo/seabios >

2 1

[PATCH] virtio-blk/scsi: enable multi-queues support when starting device
by Changpeng Liu 26 Sep '18

26 Sep '18

QEMU will not start all the queues since commit fb20fbb76 "vhost: avoid to start/stop virtqueue which is not read", because seabios only use one queue when starting, this will not work for some vhost slave targets which expect the exact number of queues defined in virtio-pci configuration space, while here, we also enable those queues in the BIOS phase. Signed-off-by: Changpeng Liu <changpeng.liu(a)intel.com> --- src/hw/virtio-blk.c | 26 +++++++++++++++++++------- src/hw/virtio-ring.h | 1 + src/hw/virtio-scsi.c | 28 +++++++++++++++++++--------- 3 files changed, 39 insertions(+), 16 deletions(-) diff --git a/src/hw/virtio-blk.c b/src/hw/virtio-blk.c index 88d7e54..79638ec 100644 --- a/src/hw/virtio-blk.c +++ b/src/hw/virtio-blk.c @@ -25,7 +25,7 @@ struct virtiodrive_s { struct drive_s drive; - struct vring_virtqueue *vq; + struct vring_virtqueue *vq[MAX_NUM_QUEUES]; struct vp_device vp; }; @@ -34,7 +34,7 @@ virtio_blk_op(struct disk_op_s *op, int write) { struct virtiodrive_s *vdrive = container_of(op->drive_fl, struct virtiodrive_s, drive); - struct vring_virtqueue *vq = vdrive->vq; + struct vring_virtqueue *vq = vdrive->vq[0]; struct virtio_blk_outhdr hdr = { .type = write ? VIRTIO_BLK_T_OUT : VIRTIO_BLK_T_IN, .ioprio = 0, @@ -96,6 +96,7 @@ virtio_blk_process_op(struct disk_op_s *op) static void init_virtio_blk(void *data) { + u32 i, num_queues = 1; struct pci_device *pci = data; u8 status = VIRTIO_CONFIG_S_ACKNOWLEDGE | VIRTIO_CONFIG_S_DRIVER; dprintf(1, "found virtio-blk at %pP\n", pci); @@ -109,10 +110,6 @@ init_virtio_blk(void *data) vdrive->drive.cntl_id = pci->bdf; vp_init_simple(&vdrive->vp, pci); - if (vp_find_vq(&vdrive->vp, 0, &vdrive->vq) < 0 ) { - dprintf(1, "fail to find vq for virtio-blk %pP\n", pci); - goto fail; - } if (vdrive->vp.use_modern) { struct vp_device *vp = &vdrive->vp; @@ -156,6 +153,11 @@ init_virtio_blk(void *data) vp_read(&vp->device, struct virtio_blk_config, heads); vdrive->drive.pchs.sector = vp_read(&vp->device, struct virtio_blk_config, sectors); + + num_queues = vp_read(&vp->common, virtio_pci_common_cfg, num_queues); + if (num_queues < 1 || num_queues > MAX_NUM_QUEUES) { + num_queues = 1; + } } else { struct virtio_blk_config cfg; vp_get_legacy(&vdrive->vp, 0, &cfg, sizeof(cfg)); @@ -178,6 +180,13 @@ init_virtio_blk(void *data) vdrive->drive.pchs.sector = cfg.sectors; } + for (i = 0; i < num_queues; i++) { + if (vp_find_vq(&vdrive->vp, i, &vdrive->vq[i]) < 0 ) { + dprintf(1, "fail to find vq %u for virtio-blk %pP\n", i, pci); + goto fail_vq; + } + } + char *desc = znprintf(MAXDESCSIZE, "Virtio disk PCI:%pP", pci); boot_add_hd(&vdrive->drive, desc, bootprio_find_pci_device(pci)); @@ -185,9 +194,12 @@ init_virtio_blk(void *data) vp_set_status(&vdrive->vp, status); return; +fail_vq: + for (i = 0; i < num_queues; i++) { + free(vdrive->vq[i]); + } fail: vp_reset(&vdrive->vp); - free(vdrive->vq); free(vdrive); } diff --git a/src/hw/virtio-ring.h b/src/hw/virtio-ring.h index 8604a01..3c8a2d1 100644 --- a/src/hw/virtio-ring.h +++ b/src/hw/virtio-ring.h @@ -21,6 +21,7 @@ #define VIRTIO_F_IOMMU_PLATFORM 33 #define MAX_QUEUE_NUM (128) +#define MAX_NUM_QUEUES (128) #define VRING_DESC_F_NEXT 1 #define VRING_DESC_F_WRITE 2 diff --git a/src/hw/virtio-scsi.c b/src/hw/virtio-scsi.c index a87cad8..d08643f 100644 --- a/src/hw/virtio-scsi.c +++ b/src/hw/virtio-scsi.c @@ -148,9 +148,10 @@ virtio_scsi_scan_target(struct pci_device *pci, struct vp_device *vp, static void init_virtio_scsi(void *data) { + u32 i, num_queues = 3; struct pci_device *pci = data; dprintf(1, "found virtio-scsi at %pP\n", pci); - struct vring_virtqueue *vq = NULL; + struct vring_virtqueue *vq[MAX_NUM_QUEUES]; struct vp_device *vp = malloc_high(sizeof(*vp)); if (!vp) { warn_noalloc(); @@ -175,29 +176,38 @@ init_virtio_scsi(void *data) dprintf(1, "device didn't accept features: %pP\n", pci); goto fail; } + + num_queues = vp_read(&vp->common, virtio_pci_common_cfg, num_queues); + if (num_queues < 3 || num_queues > MAX_NUM_QUEUES) { + num_queues = 3; + } } - if (vp_find_vq(vp, 2, &vq) < 0 ) { - dprintf(1, "fail to find vq for virtio-scsi %pP\n", pci); - goto fail; + for (i = 0; i < num_queues; i++) { + if (vp_find_vq(vp, i, &vq[i]) < 0 ) { + dprintf(1, "fail to find vq %u for virtio-scsi %pP\n", i, pci); + goto fail; + } } status |= VIRTIO_CONFIG_S_DRIVER_OK; vp_set_status(vp, status); - int i, tot; + int tot; for (tot = 0, i = 0; i < 256; i++) - tot += virtio_scsi_scan_target(pci, vp, vq, i); + tot += virtio_scsi_scan_target(pci, vp, vq[2], i); if (!tot) - goto fail; + goto fail_vq; return; - +fail_vq: + for (i = 0; i < num_queues; i++) { + free(vq[i]); + } fail: vp_reset(vp); free(vp); - free(vq); } void -- 1.9.3

2 1

Re: [SeaBIOS] [PATCH v2 1/1] SeaVGABios/cbvga: Fix bpp for coreboot framebuffer
by Kevin O'Connor 18 Sep '18

18 Sep '18

On Tue, Sep 11, 2018 at 09:29:39PM -0500, Matt DeVillier wrote: > Commit 4b42cc4 [SeaVGABios/cbvga: Advertise correct pixel format] neglected > to wrap the cbfb mask size components in GET_FARVAR(), which resulted in a > bogus value for bpp, breaking output on most/all devices. Fix this by > adding GET_FARVAR() as appropriate. > > Additionally, some newer ChromeOS devices still fail even with this fix, > so fall back to using the coreboot reported bit depth if the calculated > valid is invalid. Thanks. I committed this change. -Kevin

1 0

[PATCH] - Add total usable memory to startup console output
by Damien Zammit 14 Sep '18

14 Sep '18

Hi folks, I want to put forth this patch for your review. In my opinion, it is very useful to know just after your machine has POSTed how much system RAM the machine has access to. This patch prints out to the screen just under the UUID the following line: System RAM: X MB where X is the number of whole megabytes available to the system. Since the memory map is already available to SeaBIOS, I think it makes sense to total up the sizes of regions marked as E820_RAM and print the grand total. I have tested this on a coreboot QEMU bios with custom SeaBIOS built: SeaBIOS (version rel-1.11.0-46-g18e193d) System RAM: 1022 MB When I tried flashing a compatible image to my Lenovo X220 laptop it bricked it. I'm not sure why, maybe I compiled it wrong or inserted it into my image wrongly with cbfstool. Cheers, Damien

2 1

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

SeaBIOS September 2018