SeaBIOS

seabios@seabios.org

3783 discussions

Re: [SeaBIOS] Fwd: [RFC 0/2] (Ongoing)Support multiple pci domains in pci_device
by Kevin O'Connor 21 Aug '18

21 Aug '18

On Thu, Aug 09, 2018 at 07:44:22AM +0800, Zihan Yang wrote: > Kevin O'Connor <kevin(a)koconnor.net> 于2018年8月8日周三下午10:14写道： > > On Thu, Aug 02, 2018 at 10:39:13AM +0800, Zihan Yang wrote: > > > NOTE: This patch set is still ongoing and does not fully function > > > as its goal. But it involves some API changes, therefore I post them for > > > comments before moving on to make sure I'm on the right path. > > > > > > The corresponding qemu part can be found at > > > https://gitlab.com/WhoisZihan/qemu-pci-domain/tree/master/qemu > > > I will submit it to qemu list later. > > > > > > 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. > > > > Thanks. I understand the desire to support multiple PCI domains in > > QEMU and the guest OS. However, what is the high level reason for > > wanting the BIOS to be able to interact with the secondary PCI > > domains? > > The pxb-pcie host bus is put into a separated domain, so are the devices > under the pxb host bus. I think we should also initialize busses in other > domains and probe those devices during bios initialization. But currently > qemu only binds port 0xcf8 and 0xcfc to q35 host's conf_mem and data_mem, > if we want to read the config space of pxb host, we should use another port. > I use port range 0x1000 and 0x1004 for a temporary workaround because they > seem to be 'free' now. The patchset is quite large and touches a large amount of code in different parts of SeaBIOS. I'd like to understand the high-level, user-visible, reason for making the change. What important capabilities will a user be unable to accomplish if we don't make this change? As far as I know, there is no standard for accessing PCI besides the main one at cf8/cfc - so I'm not sure there is a good solution to this problem. Perhaps it would be easier for users to always put their boot devices on the main PCI. Thanks, -Kevin

1 0

Re: [SeaBIOS] enable log path of devices in seabios
by Kevin O'Connor 21 Aug '18

21 Aug '18

On Thu, Aug 09, 2018 at 12:00:49AM -0300, zahra rahimkhani wrote: > Hello Friends > > I want to enable a log that show path of devices that by seabios was > recognize . > this paths are different from boot default paths. > > Could you suggest me a advice? There's some info on generating a log file at: https://www.seabios.org/Debugging -Kevin

1 0

Re: [SeaBIOS] [Qemu-devel] [PATCH v2 0/3] hw/pci: PCI resource reserve capability
by Laszlo Ersek 17 Aug '18

17 Aug '18

Hi, On 08/16/18 11:28, Jing Liu wrote: > This patch serial is about PCI resource reserve capability. > > First patch refactors the resource reserve fields in GenPCIERoorPort > structure out to another new structure, called "PCIResReserve". Modify > the parameter list of pci_bridge_qemu_reserve_cap_init(). > > Then we add the teardown function called pci_bridge_qemu_reserve_cap_uninit(). > > Last we enable the resource reserve capability for legacy PCI bridge > so that firmware can reserve additional resources for the bridge. > > Change Log: > v2 -> v1 > * add refactoring patch > * add teardown function > * some other fixes > > Jing Liu (3): > hw/pci: factor PCI reserve resources to a separate structure > hw/pci: add teardown function for PCI resource reserve capability > hw/pci: add PCI resource reserve capability to legacy PCI bridge > > hw/pci-bridge/gen_pcie_root_port.c | 32 +++++++++++++------------- > hw/pci-bridge/pci_bridge_dev.c | 25 ++++++++++++++++++++ > hw/pci/pci_bridge.c | 47 +++++++++++++++++++++----------------- > include/hw/pci/pci_bridge.h | 18 +++++++++++---- > 4 files changed, 80 insertions(+), 42 deletions(-) > just some meta comments for now: - I've added Marcel; please keep him CC'd on this set (and the SeaBIOS counterpart, [SeaBIOS] [PATCH v2 0/3] pci: resource reserve capability found) - my task queue has blown up and I'm unsure when I'll get to reviewing this set. The same applies to the SeaBIOS counterpart. This is just to say that you should feel free to go ahead and work with the (sub)maintainers; I'll try to get back to this as time allows, but don't wait for me. If further versions are necessary, I'd appreciate being CC'd on those, just so I know what to look at when I find the time again. Thanks! Laszlo

2 1

RS232 mouse in Qemu
by Peter Fodrek ml 16 Aug '18

16 Aug '18

Dear Seabios experts, I am asking here, because only aswer to my questions to Qemu experts or Another opensource forums was that this feature is needed be supported by QEMU or SeaBIOS. Our company would like to use QEMU for DOS based program that requires msmouse driver - seems to work only with RS232 mouse- from year of 1998., yet But in Qemu it cannot use this mouse even tried to use several command line options in Windows based machine. Another function sworks well, as well as not so accurate pointing via arrow keys. Is there anybody, who is able to send recommendation fo me, please? If so I would be happy to receive tips in thje reply,please I look forward hearing from you. Yours faithfully Peter Fodrek

3 2

Re: [SeaBIOS] [PATCH v2 3/3] pci: recognize RH PCI legacy bridge resource reservation capability
by Liu, Jing2 16 Aug '18

16 Aug '18

On 8/16/2018 1:06 PM, Zihan Yang wrote: > Liu, Jing2 <jing2.liu(a)linux.intel.com> 于2018年8月16日周四上午10:39写道： >> >> Hi Zihan, >> >> I copy your comments of this patch several days ago here, >> and hope we could continue some discussion in this serial. > > Hi Jing, > > Sorry for the delay. I tested at the code just now and find that pcie > bridge does not > use a vendor specific capability. I met this warning in another > ongoing patch so I just > added pcie bridge to suppress the warning. > > Now that it turns out pcie bridge does not use this vendor specific > capability, I think you > might want to stick with your original patch, and add it in the future > when redhat decides > to add specific capabilities in pcie bridge. Yes, I agree. I'm not quite an expert > in this field, so unfortunately > I don't have much insights to give, but I'm open for a discussion. > Thanks, Jing

1 0

[PATCH v2 0/3] pci: resource reserve capability found
by Jing Liu 15 Aug '18

15 Aug '18

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

3 5

[PATCH v2 3/3] pci: recognize RH PCI legacy bridge resource
by Jing Liu 14 Aug '18

14 Aug '18

Enable the firmware recognizing RedHat legacy PCI bridge device ID, so QEMU can reserve additional PCI bridge resource capability. Signed-off-by: Jing Liu <jing2.liu(a)linux.intel.com> --- src/fw/pciinit.c | 50 +++++++++++++++++++++++++++++--------------------- src/hw/pci_ids.h | 1 + 2 files changed, 30 insertions(+), 21 deletions(-) diff --git a/src/fw/pciinit.c b/src/fw/pciinit.c index 62a32f1..795d84a 100644 --- a/src/fw/pciinit.c +++ b/src/fw/pciinit.c @@ -525,30 +525,38 @@ static void pci_bios_init_platform(void) static u8 pci_find_resource_reserve_capability(u16 bdf) { - if (pci_config_readw(bdf, PCI_VENDOR_ID) == PCI_VENDOR_ID_REDHAT && - pci_config_readw(bdf, PCI_DEVICE_ID) == - PCI_DEVICE_ID_REDHAT_ROOT_PORT) { - u8 cap = 0; - do { - cap = pci_find_capability(bdf, PCI_CAP_ID_VNDR, cap); - } while (cap && - pci_config_readb(bdf, cap + PCI_CAP_REDHAT_TYPE_OFFSET) != - REDHAT_CAP_RESOURCE_RESERVE); - if (cap) { - u8 cap_len = pci_config_readb(bdf, cap + PCI_CAP_FLAGS); - if (cap_len < RES_RESERVE_CAP_SIZE) { - dprintf(1, "PCI: QEMU resource reserve cap length %d is invalid\n", - cap_len); - return 0; - } - } else { - dprintf(1, "PCI: QEMU resource reserve cap not found\n"); + u16 device_id; + + if (pci_config_readw(bdf, PCI_VENDOR_ID) != PCI_VENDOR_ID_REDHAT) { + dprintf(1, "PCI: QEMU resource reserve cap vendor ID doesn't match.\n"); + return 0; + } + + device_id = pci_config_readw(bdf, PCI_DEVICE_ID); + + if (device_id != PCI_DEVICE_ID_REDHAT_ROOT_PORT && + device_id != PCI_DEVICE_ID_REDHAT_BRIDGE) { + dprintf(1, "PCI: QEMU resource reserve cap device ID doesn't match.\n"); + return 0; + } + u8 cap = 0; + + do { + cap = pci_find_capability(bdf, PCI_CAP_ID_VNDR, cap); + } while (cap && + pci_config_readb(bdf, cap + PCI_CAP_REDHAT_TYPE_OFFSET) != + REDHAT_CAP_RESOURCE_RESERVE); + if (cap) { + u8 cap_len = pci_config_readb(bdf, cap + PCI_CAP_FLAGS); + if (cap_len < RES_RESERVE_CAP_SIZE) { + dprintf(1, "PCI: QEMU resource reserve cap length %d is invalid\n", + cap_len); + return 0; } - return cap; } else { - dprintf(1, "PCI: QEMU resource reserve cap VID or DID doesn't match.\n"); - return 0; + dprintf(1, "PCI: QEMU resource reserve cap not found\n"); } + return cap; } /**************************************************************** diff --git a/src/hw/pci_ids.h b/src/hw/pci_ids.h index 38fa2ca..1096461 100644 --- a/src/hw/pci_ids.h +++ b/src/hw/pci_ids.h @@ -2265,6 +2265,7 @@ #define PCI_VENDOR_ID_REDHAT 0x1b36 #define PCI_DEVICE_ID_REDHAT_ROOT_PORT 0x000C +#define PCI_DEVICE_ID_REDHAT_BRIDGE 0x0001 #define PCI_VENDOR_ID_TEKRAM 0x1de1 #define PCI_DEVICE_ID_TEKRAM_DC290 0xdc29 -- 1.8.3.1

3 2

[SEABIOS] [PATCH 1/1] nvme: fix I/O queue length calculation overflow
by Matt DeVillier 13 Aug '18

13 Aug '18

>From a17975b5fe0cb2b17fdf0335430d5f4d2ab3ba4d Mon Sep 17 00:00:00 2001 From: Matt DeVillier <matt.devillier(a)gmail.com> Date: Sun, 12 Aug 2018 15:26:59 -0500 Subject: [PATCH 1/1] nvme: fix I/O queue length calculation overflow Commit cd47172 changed the I/O queue length calculation to use the Maximum Queue Entries Supported (MQES) value from the capabilities register, plus one, with a maximum value of NVME_PAGE_SIZE. An unintended effect from this is that a MQES value of 0xFFFF yields a length of zero, resulting in the queue allocation failing. Fix this by checking for a zero length when checking that the length exceeds NVME_PAGE_SIZE, and setting to NVME_PAGE_SIZE. TEST: build/boot on a Purism Librem13v2 with a MyDigitalSSD BPX NVMe drive, which reports a MQES of 0xFFFF. Verify NVMe drive present in boot menu and OS boots successfully. Signed-off-by: Matt DeVillier <matt.devillier(a)gmail.com> --- src/hw/nvme.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/src/hw/nvme.c b/src/hw/nvme.c index e6d739d..c2d6863 100644 --- a/src/hw/nvme.c +++ b/src/hw/nvme.c @@ -319,7 +319,7 @@ nvme_create_io_cq(struct nvme_ctrl *ctrl, struct nvme_cq *cq, u16 q_idx) int rc; struct nvme_sqe *cmd_create_cq; u16 length = 1 + (ctrl->reg->cap & 0xffff); - if (length > NVME_PAGE_SIZE / sizeof(struct nvme_cqe)) + if (length == 0 || length > NVME_PAGE_SIZE / sizeof(struct nvme_cqe)) length = NVME_PAGE_SIZE / sizeof(struct nvme_cqe); rc = nvme_init_cq(ctrl, cq, q_idx, length); @@ -363,7 +363,7 @@ nvme_create_io_sq(struct nvme_ctrl *ctrl, struct nvme_sq *sq, u16 q_idx, struct int rc; struct nvme_sqe *cmd_create_sq; u16 length = 1 + (ctrl->reg->cap & 0xffff); - if (length > NVME_PAGE_SIZE / sizeof(struct nvme_cqe)) + if (length == 0 || length > NVME_PAGE_SIZE / sizeof(struct nvme_cqe)) length = NVME_PAGE_SIZE / sizeof(struct nvme_cqe); rc = nvme_init_sq(ctrl, sq, q_idx, length, cq); -- 2.17.1

1 0

Re: [SeaBIOS] Marvell 88SE9230 passthrough in KVM takes long time to boot
by Gerd Hoffmann 09 Aug '18

09 Aug '18

On Sun, Jul 29, 2018 at 01:49:10PM +0200, Konrad Eisele wrote: > I'm passing through a Marvell 88SE9230 card to a KVM guest under > Ubuntu 18.04. The card is a Sata controller with 4 ports. > The option rom of the Marvell 88SE9230 card shows on a normal boot a > bios screen. When pressing CTRL-m quick enough, you can interrupt the > bootprocess and enter a menue wherer you can define raid > arrays. > > When booting seabios inside KVM the bootprocess is very slow. > There is a 1 min holdtime where the cpu is about 30%. The screen is > black with only the seabios version string shown. I suspect that > the passed-through Marvell 88SE9230 cards option roms causes this > behaviour. > Maybe the scanning for option rom cause the slow bootprocess? > > In the seabios boot case no bios menue is shown, after > around 1 min the boot continues. > > Is it possible to disable the options rom processing? Is there some > documentation about this (How can I configure it for Ubuntu) ? Set the romfile option to the empty string (for vfio-pci, on the qemu command line) should do that (qemu will not expose the rom to the guest then). cheers, Gerd

3 2

enable log path of devices in seabios
by zahra rahimkhani 09 Aug '18

09 Aug '18

Hello Friends I want to enable a log that show path of devices that by seabios was recognize . this paths are different from boot default paths. Could you suggest me a advice? Thank you, Zahra

1 0

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

SeaBIOS