SeaBIOS July 2017

seabios@seabios.org

19 participants
46 discussions

Re: [SeaBIOS] [PATCH] Support multiple hard disks in boot list.
by Kevin O'Connor 20 Jul '17

20 Jul '17

On Thu, Jul 13, 2017 at 05:30:43PM -0700, Gaurav Poothia wrote: > Hi Kevin, > I also tried this patch to fallback from non bootable SCSI disk to > bootable SCSI disk with Windows installed. That worked too. > So while we cannot see the Windows bootloader source it sure seems to > be honoring the DL values other than 0x80 Thanks. I tried a handful of images I had handy and found a bunch of failures (see testing patch I used below). lilo - failed freedos - failed subtly winxp - failed winvista - success fedora 13 disk - failed Unfortunately, I don't think this is a change that could be made without near universal support. As, when it does fail, it fails in a very cryptic way. I think it would be more pain for users than gain. -Kevin --- a/src/boot.c +++ b/src/boot.c @@ -731,7 +731,7 @@ do_boot(int seq_nr) break; case IPL_TYPE_HARDDISK: printf("Booting from Hard Disk...\n"); - boot_disk(0x80, 1); + boot_disk(0x81, 1); break; case IPL_TYPE_CDROM: boot_cdrom((void*)ie->vector);

1 0

[PATCH 1/2] usb: add hub portmap
by Gerd Hoffmann 20 Jul '17

20 Jul '17

Allow usb hubs to map (software) ports to physical ports via op callback. This is needed to make bootorder work in case there isn't a simple linear mapping. Signed-off-by: Gerd Hoffmann <kraxel(a)redhat.com> --- src/hw/usb.h | 1 + src/boot.c | 11 +++++++++-- 2 files changed, 10 insertions(+), 2 deletions(-) diff --git a/src/hw/usb.h b/src/hw/usb.h index 94e12b20dd..2cfb572177 100644 --- a/src/hw/usb.h +++ b/src/hw/usb.h @@ -56,6 +56,7 @@ struct usbhub_s { struct usbhub_op_s { int (*detect)(struct usbhub_s *hub, u32 port); int (*reset)(struct usbhub_s *hub, u32 port); + int (*portmap)(struct usbhub_s *hub, u32 port); void (*disconnect)(struct usbhub_s *hub, u32 port); }; diff --git a/src/boot.c b/src/boot.c index 59623fb63d..8f6802c89b 100644 --- a/src/boot.c +++ b/src/boot.c @@ -207,6 +207,13 @@ int bootprio_find_named_rom(const char *name, int instance) return find_prio(desc); } +static int usb_portmap(struct usbdevice_s *usbdev) +{ + if (usbdev->hub->op->portmap) + return usbdev->hub->op->portmap(usbdev->hub, usbdev->port); + return usbdev->port + 1; +} + static char * build_usb_path(char *buf, int max, struct usbhub_s *hub) { @@ -214,7 +221,7 @@ build_usb_path(char *buf, int max, struct usbhub_s *hub) // Root hub - nothing to add. return buf; char *p = build_usb_path(buf, max, hub->usbdev->hub); - p += snprintf(p, buf+max-p, "/hub@%x", hub->usbdev->port+1); + p += snprintf(p, buf+max-p, "/hub@%x", usb_portmap(hub->usbdev)); return p; } @@ -232,7 +239,7 @@ int bootprio_find_usb(struct usbdevice_s *usbdev, int lun) if (ret >= 0) return ret; // Try usb-host/redir - for example: /pci@i0cf8/usb@1,2/usb-host@1 - snprintf(p, desc+sizeof(desc)-p, "/usb-*@%x", usbdev->port+1); + snprintf(p, desc+sizeof(desc)-p, "/usb-*@%x", usb_portmap(usbdev)); return find_prio(desc); } -- 2.9.3

3 4

Re: [SeaBIOS] [Qemu-devel] Fwd: [RFC PATCH 0/2] Allow RedHat PCI bridges reserve more buses than necessary during init
by Konrad Rzeszutek Wilk 19 Jul '17

19 Jul '17

On Wed, Jul 19, 2017 at 09:38:50PM +0300, Alexander Bezzubikov wrote: > 2017-07-19 21:18 GMT+03:00 Konrad Rzeszutek Wilk <konrad.wilk(a)oracle.com>: > > > On Wed, Jul 19, 2017 at 05:14:41PM +0000, Alexander Bezzubikov wrote: > > > ср, 19 июля 2017 г. в 16:57, Konrad Rzeszutek Wilk < > > konrad.wilk(a)oracle.com>: > > > > > > > On Wed, Jul 19, 2017 at 04:20:12PM +0300, Aleksandr Bezzubikov wrote: > > > > > Now PCI bridges (and PCIE root port too) get a bus range number in > > > > system init, > > > > > basing on currently plugged devices. That's why when one wants to > > > > hotplug another bridge, > > > > > it needs his child bus, which the parent is unable to provide. > > > > > > > > Could you explain how you trigger this? > > > > > > > > > I'm trying to hot plug pcie-pci bridge into pcie root port, and Linux > > says > > > 'cannot allocate bus number for device bla-bla'. This obviously does not > > > allow me to use the bridge at all. > > > > > > > > > > > > > > > > The suggested workaround is to have vendor-specific capability in > > RedHat > > > > generic pcie-root-port > > > > > that contains number of additional bus to reserve on BIOS PCI init. > > > > > > > > But wouldn't the proper fix be for the PCI bridge to have the > > subordinate > > > > value be extended to fit more bus ranges? > > > > > > > > > What do you mean? This is what I'm trying to do. Do you suppose to get > > rid > > > of vendor-specific cap and use original register value instead of it? > > > > I would suggest a simple fix - each bridge has a a number of bus devices > > it can use. You have up to 255 - so you split the number of northbridge > > numbers by the amount of NUMA nodes (if that is used) - so for example > > if you have 4 NUMA nodes, each bridge would cover 63 bus numbers. > > > > Meaning the root bridge would cover 0->63 bus, 64->128, and so on. > > That gives you enough space to plug in your plugged in devices > > (up to 63). > > > > And if you need sub-briges then carve out a specific range. > > > > The problem is that we don't know at the init moment how many subbridges we > may need, And the explanation above does not either. It just setups at init time an range where you can plug in your new devices in. But in a more uniform way such that you can also utilize this with NUMA and _PXM topology in the future. > and how deep the whole device tree will be. The key moment - PCI bridge > hotplugging > needs either rescan all buses on each bridge device addition, or reserve > space in advance during BIOS init. can all buses on each bridge device addition, or reserve It is more complex than that - you may need to move devices that are below you. And Linux kernel (nor any other OS) can handle that. (They can during bootup) > In this series the second way was chosen. > > > > > > > > > > > > > > > > > > > > > > > Aleksandr Bezzubikov (2): > > > > > pci: add support for direct usage of bdf for capability lookup > > > > > pci: enable RedHat pci bridges to reserve more buses > > > > > > > > > > src/fw/pciinit.c | 12 ++++++++++-- > > > > > src/hw/pcidevice.c | 24 ++++++++++++++++++++++++ > > > > > src/hw/pcidevice.h | 1 + > > > > > 3 files changed, 35 insertions(+), 2 deletions(-) > > > > > > > > > > -- > > > > > 2.7.4 > > > > > > > > > > > > > > > > > -- > > > Alexander Bezzubikov > > > > > > -- > Alexander Bezzubikov

2 1

Fwd: [Qemu-devel] [RFC PATCH 0/2] Allow RedHat PCI bridges reserve more buses than necessary during init
by Alexander Bezzubikov 19 Jul '17

19 Jul '17

2017-07-19 21:18 GMT+03:00 Konrad Rzeszutek Wilk <konrad.wilk(a)oracle.com>: > On Wed, Jul 19, 2017 at 05:14:41PM +0000, Alexander Bezzubikov wrote: > > ср, 19 июля 2017 г. в 16:57, Konrad Rzeszutek Wilk < > konrad.wilk(a)oracle.com>: > > > > > On Wed, Jul 19, 2017 at 04:20:12PM +0300, Aleksandr Bezzubikov wrote: > > > > Now PCI bridges (and PCIE root port too) get a bus range number in > > > system init, > > > > basing on currently plugged devices. That's why when one wants to > > > hotplug another bridge, > > > > it needs his child bus, which the parent is unable to provide. > > > > > > Could you explain how you trigger this? > > > > > > I'm trying to hot plug pcie-pci bridge into pcie root port, and Linux > says > > 'cannot allocate bus number for device bla-bla'. This obviously does not > > allow me to use the bridge at all. > > > > > > > > > > > > The suggested workaround is to have vendor-specific capability in > RedHat > > > generic pcie-root-port > > > > that contains number of additional bus to reserve on BIOS PCI init. > > > > > > But wouldn't the proper fix be for the PCI bridge to have the > subordinate > > > value be extended to fit more bus ranges? > > > > > > What do you mean? This is what I'm trying to do. Do you suppose to get > rid > > of vendor-specific cap and use original register value instead of it? > > I would suggest a simple fix - each bridge has a a number of bus devices > it can use. You have up to 255 - so you split the number of northbridge > numbers by the amount of NUMA nodes (if that is used) - so for example > if you have 4 NUMA nodes, each bridge would cover 63 bus numbers. > > Meaning the root bridge would cover 0->63 bus, 64->128, and so on. > That gives you enough space to plug in your plugged in devices > (up to 63). > > And if you need sub-briges then carve out a specific range. > The problem is that we don't know at the init moment how many subbridges we may need, and how deep the whole device tree will be. The key moment - PCI bridge hotplugging needs either rescan all buses on each bridge device addition, or reserve space in advance during BIOS init. In this series the second way was chosen. > > > > > > > > > > > > > > > Aleksandr Bezzubikov (2): > > > > pci: add support for direct usage of bdf for capability lookup > > > > pci: enable RedHat pci bridges to reserve more buses > > > > > > > > src/fw/pciinit.c | 12 ++++++++++-- > > > > src/hw/pcidevice.c | 24 ++++++++++++++++++++++++ > > > > src/hw/pcidevice.h | 1 + > > > > 3 files changed, 35 insertions(+), 2 deletions(-) > > > > > > > > -- > > > > 2.7.4 > > > > > > > > > > > > > -- > > Alexander Bezzubikov > -- Alexander Bezzubikov

1 0

Re: [SeaBIOS] [Qemu-devel] [RFC PATCH 0/2] Allow RedHat PCI bridges reserve more buses than necessary during init
by Konrad Rzeszutek Wilk 19 Jul '17

19 Jul '17

On Wed, Jul 19, 2017 at 05:14:41PM +0000, Alexander Bezzubikov wrote: > ср, 19 июля 2017 г. в 16:57, Konrad Rzeszutek Wilk <konrad.wilk(a)oracle.com>: > > > On Wed, Jul 19, 2017 at 04:20:12PM +0300, Aleksandr Bezzubikov wrote: > > > Now PCI bridges (and PCIE root port too) get a bus range number in > > system init, > > > basing on currently plugged devices. That's why when one wants to > > hotplug another bridge, > > > it needs his child bus, which the parent is unable to provide. > > > > Could you explain how you trigger this? > > > I'm trying to hot plug pcie-pci bridge into pcie root port, and Linux says > 'cannot allocate bus number for device bla-bla'. This obviously does not > allow me to use the bridge at all. > > > > > > > > The suggested workaround is to have vendor-specific capability in RedHat > > generic pcie-root-port > > > that contains number of additional bus to reserve on BIOS PCI init. > > > > But wouldn't the proper fix be for the PCI bridge to have the subordinate > > value be extended to fit more bus ranges? > > > What do you mean? This is what I'm trying to do. Do you suppose to get rid > of vendor-specific cap and use original register value instead of it? I would suggest a simple fix - each bridge has a a number of bus devices it can use. You have up to 255 - so you split the number of northbridge numbers by the amount of NUMA nodes (if that is used) - so for example if you have 4 NUMA nodes, each bridge would cover 63 bus numbers. Meaning the root bridge would cover 0->63 bus, 64->128, and so on. That gives you enough space to plug in your plugged in devices (up to 63). And if you need sub-briges then carve out a specific range. > > > > > > > > > Aleksandr Bezzubikov (2): > > > pci: add support for direct usage of bdf for capability lookup > > > pci: enable RedHat pci bridges to reserve more buses > > > > > > src/fw/pciinit.c | 12 ++++++++++-- > > > src/hw/pcidevice.c | 24 ++++++++++++++++++++++++ > > > src/hw/pcidevice.h | 1 + > > > 3 files changed, 35 insertions(+), 2 deletions(-) > > > > > > -- > > > 2.7.4 > > > > > > > > > -- > Alexander Bezzubikov

1 0

Re: [SeaBIOS] [Qemu-devel] [Question] Seabios HANGs when mmio wirte in a nested vmware host wtih virito-scsi controller
by Xiao Guangrong 17 Jul '17

17 Jul '17

On 07/17/2017 03:34 PM, Xulei (Stone) wrote: > > On 07/17/2017 11:13 AM, Xulei (Stone) wrote: > > >> |--virtio_queue_empty > >> > >> Then, kmod falls in infinite loop in handle EPT_MISCONFIG. > >> As far as i know, when kvm enters guest after handling EPT_MISCONFIG, seabios should return > >> from mmio write and wait for virtio backend(qemu) to handle this mmio writing. > >> What puzzles me: > >> 1) i can not understand why kvm runs in infinite loop and seabios does not return from writew. > > >From the trace in L1 guest, it did not hang in KVM, as it went into guest mode normally. > > >> 2) kvm nested kvm is ok. But vmware nested kvm is not ok. This problem has anything related > >> with vmware? > >> > > > It is the issue in vmware, i guess the RIP register is not handled correctly. > > BTW, does kvm unit tests run well on nested vmware? > > Sadly, kvm unit tests run fail on nested vmware and make the CentOS 7.3(with kmod 4.4.11) crashed... > Well, so that should be reported to vmware. :-)

1 0

Re: [SeaBIOS] [Qemu-devel] [Question] Seabios HANGs when mmio wirte in a nested vmware host wtih virito-scsi controller
by Xiao Guangrong 17 Jul '17

17 Jul '17

On 07/17/2017 11:13 AM, Xulei (Stone) wrote: > |--virtio_queue_empty > > Then, kmod falls in infinite loop in handle EPT_MISCONFIG. > As far as i know, when kvm enters guest after handling EPT_MISCONFIG, seabios should return > from mmio write and wait for virtio backend(qemu) to handle this mmio writing. > What puzzles me: > 1) i can not understand why kvm runs in infinite loop and seabios does not return from writew. From the trace in L1 guest, it did not hang in KVM, as it went into guest mode normally. > 2) kvm nested kvm is ok. But vmware nested kvm is not ok. This problem has anything related > with vmware? > It is the issue in vmware, i guess the RIP register is not handled correctly. BTW, does kvm unit tests run well on nested vmware?

2 1

[Question] Seabios HANGs when mmio wirte in a nested vmware host wtih virito-scsi controller
by Xulei (Stone) 17 Jul '17

17 Jul '17

Hello all, Recently, I met a werid question when i run a VM in the following platfrom: Vmware Vsphere 6.0/6.5 |-- centos 7.3 nested VM (with qemu 2.8, kmod 4.4.11, seabios 1.10) |-- VM (with virtio-scsi controller, modern mode) VM MUST hang in seabios when try to mmio write during virtio-scsi init. I deeply analyze the code, and i found that: Seabios calltrace: scsi_drive_setup |-- cdb_get_inquiry |-- virtio_scsi_process_op |-- vring_kick |-- writew (hang here, mmio write, never return...) Kmod calltrace: handle_EPT_MISCONFIG |--kvm_io_bus_write |-- kvm_iodevice_write (fast mmio through ioeventfd to trigger qemu) |-- vcpu_run |-- vcpu_enter_guest Qemu calltrace: os_host_main_loop_wait |--glib_pollfds_poll |-- aio_dispatch |-- vritio_scsi_handle_cmd_vq |--virtio_scsi_pop_req |-- virtqueue_pop |--virtio_queue_empty Then, kmod falls in infinite loop in handle EPT_MISCONFIG. As far as i know, when kvm enters guest after handling EPT_MISCONFIG, seabios should return from mmio write and wait for virtio backend(qemu) to handle this mmio writing. What puzzles me: 1) i can not understand why kvm runs in infinite loop and seabios does not return from writew. 2) kvm nested kvm is ok. But vmware nested kvm is not ok. This problem has anything related with vmware? Looking forward for directions... Attached Kmod ftrace: CPU 0/KVM-9435 [008] .... 241968.479572: kvm_exit: reason EPT_MISCONFIG rip 0xee696 info 0 0 CPU 0/KVM-9435 [008] .... 241968.479573: kvm_fast_mmio: fast mmio at gpa 0xfe003008 CPU 0/KVM-9435 [008] d... 241968.479573: kvm_entry: vcpu 0 CPU 0/KVM-9435 [008] .... 241968.479583: kvm_exit: reason EPT_MISCONFIG rip 0xee696 info 0 0 CPU 0/KVM-9435 [008] .... 241968.479589: kvm_fast_mmio: fast mmio at gpa 0xfe003008 CPU 0/KVM-9435 [008] d... 241968.479589: kvm_entry: vcpu 0 CPU 0/KVM-9435 [008] .... 241968.479599: kvm_exit: reason EPT_MISCONFIG rip 0xee696 info 0 0 CPU 0/KVM-9435 [008] .... 241968.479600: kvm_fast_mmio: fast mmio at gpa 0xfe003008 CPU 0/KVM-9435 [008] d... 241968.479601: kvm_entry: vcpu 0 CPU 0/KVM-9435 [008] .... 241968.479610: kvm_exit: reason EPT_MISCONFIG rip 0xee696 info 0 0 CPU 0/KVM-9435 [008] .... 241968.479616: kvm_fast_mmio: fast mmio at gpa 0xfe003008 CPU 0/KVM-9435 [008] d... 241968.479617: kvm_entry: vcpu 0 CPU 0/KVM-9435 [008] .... 241968.479627: kvm_exit: reason EPT_MISCONFIG rip 0xee696 info 0 0 CPU 0/KVM-9435 [008] .... 241968.479628: kvm_fast_mmio: fast mmio at gpa 0xfe003008 CPU 0/KVM-9435 [008] d... 241968.479628: kvm_entry: vcpu 0 CPU 0/KVM-9435 [008] .... 241968.479638: kvm_exit: reason EPT_MISCONFIG rip 0xee696 info 0 0 CPU 0/KVM-9435 [008] .... 241968.479644: kvm_fast_mmio: fast mmio at gpa 0xfe003008 CPU 0/KVM-9435 [008] d... 241968.479644: kvm_entry: vcpu 0 CPU 0/KVM-9435 [008] .... 241968.479655: kvm_exit: reason EPT_MISCONFIG rip 0xee696 info 0 0 CPU 0/KVM-9435 [008] .... 241968.479656: kvm_fast_mmio: fast mmio at gpa 0xfe003008 CPU 0/KVM-9435 [008] d... 241968.479656: kvm_entry: vcpu 0 ________________________________

1 0

Re: [SeaBIOS] [PATCH] Support multiple hard disks in boot list.
by Gaurav Poothia 14 Jul '17

14 Jul '17

Hi Kevin, I also tried this patch to fallback from non bootable SCSI disk to bootable SCSI disk with Windows installed. That worked too. So while we cannot see the Windows bootloader source it sure seems to be honoring the DL values other than 0x80 Thanks Gaurav On Mon, Jul 10, 2017 at 1:49 PM, Gaurav Poothia <gaurav.poothia(a)gmail.com> wrote: > Hi Kevin, > Thanks for your response! > > I have tested this successfully against grub (specifically GRUB 2) > Since you asked I went digging for the relevant code in grub - here is > the line of code that will validate range of acceptable DL values and > if acceptable jump ahead to boot from that disk and skip hardcoding DL > to 0x80: > https://github.com/coreos/grub/blob/master/grub-core/boot/i386/pc/boot.S#L2… > > So for example if bios were to set DL to 0x81 (by fallback logic in > the patch) that will be acceptable to grub > > On Fri, Jul 7, 2017 at 7:55 AM, Kevin O'Connor <kevin(a)koconnor.net> wrote: >> On Fri, Jun 30, 2017 at 08:48:27PM -0400, Gaurav Poothia wrote: >>> If multiple disks in boot order and first is unbootable >>> then fallback to other disks in list. >> [...] >>> @@ -731,7 +736,10 @@ do_boot(int seq_nr) >>> break; >>> case IPL_TYPE_HARDDISK: >>> printf("Booting from Hard Disk...\n"); >>> - boot_disk(0x80, 1); >>> + if (ie->hdid == -1) >>> + boot_disk(0x80 , 1); >>> + else >>> + boot_disk(0x80 + ie->hdid, 1); >>> break; >>> case IPL_TYPE_CDROM: >>> boot_cdrom((void*)ie->vector); >> >> Ultimately, what this patch does is set the DL register to something >> other than 0x80. I tested this approach a few years ago, and at the >> time I could not find a single bootloader that used DL. What >> bootloaders did you test with this, and which ones worked and did not >> work? >> >> -Kevin > > > > -- > Kiva.org - Loans That Change Lives -- Kiva.org - Loans That Change Lives

1 0

Re: [SeaBIOS] [PATCH] boot: boot menu up to 35 devices with letters and possible pages
by Ivan Ivanov 12 Jul '17

12 Jul '17

Maybe you are correct - it is hard to fill a page (get 18 entries) during the normal usage scenario - when not adding a lot of slightly different versions of payload for debug purposes... However, at least one person except me (Gerd Hoffmann) thought its a nice feature to have, so I decided to spend some time to implement and test it. If all the devices fit at 1 page - there will be no changes at user interface, no paging enabled. This paging enables by itself only when more than 18 entries are detected - only when it is necessary, all the other time this code is inactive If I remember correctly, applying this whole patch (with paging included) increases seabios rom size just by ~250 bytes, removing the paging wouldn't give any noticeable benefit in size. So personally I don't see any downsides and will continue using this patch at its' current version ;) 2017-07-12 2:16 GMT+03:00 Ivan Ivanov <qmastery16(a)gmail.com>: > Maybe you are correct - it is hard to fill a page (get 18 entries) > during the normal usage scenario - when not adding a lot of slightly > different versions of payload for debug purposes... However, at least > one person except me (Gerd Hoffmann) thought its a nice feature to > have, so I decided to spend some time to implement and test it. If all > the devices fit at 1 page - there will be no changes at user > interface, no paging enabled. This paging enables by itself only when > more than 18 entries are detected - only when it is necessary, all the > other time this code is inactive > > If I remember correctly, applying this whole patch (with paging > included) increases seabios rom size just by ~250 bytes, removing the > paging wouldn't give any noticeable benefit in size. So personally I > don't see any downsides and will continue using this patch at its' > current version ;) > > > 2017-07-07 17:51 GMT+03:00 Kevin O'Connor <kevin(a)koconnor.net>: >> On Sun, Jul 02, 2017 at 12:38:00AM +0300, Ivan Ivanov wrote: >>> Recently I discovered another area where this "35 devices" patch is useful. >>> When you need to debug a payload on the real coreboot-supported hardware, >>> to speed up the development you could include a lot of slightly different >>> versions of the same payload to your coreboot ROM, and then >>> could test them all after a single flashing, saving your time and >>> reducing the wearing out of SPI flash >> >> Sorry for the delay in responding. >> >> I think it would be useful to support more than 10 devices in the boot >> menu. I'm not convinced we need a paging menu though. I suspect that >> increasing the count to 20 (or whatever fits on a page) should be >> sufficient for now. >> >> -Kevin

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

SeaBIOS July 2017