From f65c435b8e3caf7249a3fb25150e7055898ccc12 Mon Sep 17 00:00:00 2001
From: gaobin <gaobin(a)amazon.com>
Date: Fri, 18 Oct 2019 23:00:21 -0700
Subject: [PATCH 4/4] serialio: Support for pci serial ports
Some Intel PCHs integrate pci uarts which are used for serial
port debugging. For compatibility purpose, BIOS implementation
may assign 0x3f8 to the pci uart's io bar at PEI stage, later
during DXE stage the pci uart's bar is re-assigned to a different
address. As a result, we can't use the hard coded IO port 0x3f8
in SeaBIOS for debugging. Instead, we need read the port base
address from the pci uart's BAR, either an IO BAR, or a 32bit
memory BAR. This patch adds support for pci serial port debugging.
Signed-off-by: gaobin <gaobin(a)amazon.com>
---
src/Kconfig | 34 +++++++++++++++++++++++++++++++++-
src/hw/serialio.c | 29 +++++++++++++++++++++++++++--
2 files changed, 60 insertions(+), 3 deletions(-)
diff --git a/src/Kconfig b/src/Kconfig
index 6606ce4..6d9ce3b 100644
--- a/src/Kconfig
+++ b/src/Kconfig
@@ -550,8 +550,40 @@ menu "Debugging"
default 0x3f8
help
Base port for serial - generally 0x3f8, 0x2f8, 0x3e8, or 0x2e8.
- config DEBUG_SERIAL_MMIO
+ config DEBUG_SERIAL_PCI_IO
depends on DEBUG_LEVEL != 0 && !DEBUG_SERIAL
+ bool "Serial port debugging via PCI IO"
+ default n
+ help
+ Send debugging information to PCI serial port.
+ The base address of the uart is in the PCI device's IO bar.
+ config DEBUG_SERIAL_PCI_MEM32
+ depends on DEBUG_LEVEL != 0 && !DEBUG_SERIAL && !DEBUG_SERIAL_PCI_IO
+ bool "Serial port debugging via PCI MEM32"
+ default n
+ help
+ Send debugging information to PCI serial port.
+ The base address of the uart is in the PCI device's MEM32 bar.
+ config DEBUG_SERIAL_PCI_BDF
+ depends on DEBUG_SERIAL_PCI_IO || DEBUG_SERIAL_PCI_MEM32
+ hex "Serial port PCI bus/device/function"
+ range 0 ffff
+ help
+ 16bit hex of B:D:F of the PCI serial port.
+ Bit 15:8 - bus, bit 7:3 - device, bit 2:0 - function
+ E.g. for a PCI device: bus 0x0, dev 0x1a, func 0x1 you
+ should input 00d1.
+ config DEBUG_SERIAL_PCI_BAR
+ depends on DEBUG_SERIAL_PCI_IO || DEBUG_SERIAL_PCI_MEM32
+ hex "Serial port PCI BAR index (0 - 5)"
+ range 0 5
+ default 0
+ help
+ The index of the BAR where the base address would be read
+ from for the PCI serial port. Only IO BAR and 32bit memory
+ BAR are supported.
+ config DEBUG_SERIAL_MMIO
+ depends on DEBUG_LEVEL != 0 && !DEBUG_SERIAL && !DEBUG_SERIAL_PCI_IO && !DEBUG_SERIAL_PCI_MEM32
bool "Serial port debugging via memory mapped IO"
default n
help
diff --git a/src/hw/serialio.c b/src/hw/serialio.c
index 3163344..9a8565c 100644
--- a/src/hw/serialio.c
+++ b/src/hw/serialio.c
@@ -9,6 +9,7 @@
#include "output.h" // dprintf
#include "serialio.h" // serial_debug_preinit
#include "x86.h" // outb
+#include "pci.h" //pci_config_readw
/****************************************************************
@@ -23,6 +24,15 @@ serial_debug_write(u8 offset, u8 val)
{
if (CONFIG_DEBUG_SERIAL) {
outb(val, CONFIG_DEBUG_SERIAL_PORT + offset);
+ } else if (CONFIG_DEBUG_SERIAL_PCI_IO) {
+ u16 base = pci_config_readw(CONFIG_DEBUG_SERIAL_PCI_BDF,
+ 0x10 + CONFIG_DEBUG_SERIAL_PCI_BAR*4) & (~0x3);
+ outb(val, base + offset);
+ } else if (CONFIG_DEBUG_SERIAL_PCI_MEM32) {
+ ASSERT32FLAT();
+ u32 base = pci_config_readl(CONFIG_DEBUG_SERIAL_PCI_BDF,
+ 0x10 + CONFIG_DEBUG_SERIAL_PCI_BAR*4) & (~0x7);
+ writeb((void*)base + 4*offset, val);
} else if (CONFIG_DEBUG_SERIAL_MMIO) {
ASSERT32FLAT();
writeb((void*)CONFIG_DEBUG_SERIAL_MEM_ADDRESS + 4*offset, val);
@@ -35,6 +45,17 @@ serial_debug_read(u8 offset)
{
if (CONFIG_DEBUG_SERIAL)
return inb(CONFIG_DEBUG_SERIAL_PORT + offset);
+ if (CONFIG_DEBUG_SERIAL_PCI_IO) {
+ u16 base = pci_config_readw(CONFIG_DEBUG_SERIAL_PCI_BDF,
+ 0x10 + CONFIG_DEBUG_SERIAL_PCI_BAR*4) & (~0x3);
+ return inb(base + offset);
+ }
+ if (CONFIG_DEBUG_SERIAL_PCI_MEM32) {
+ ASSERT32FLAT();
+ u32 base = pci_config_readl(CONFIG_DEBUG_SERIAL_PCI_BDF,
+ 0x10 + CONFIG_DEBUG_SERIAL_PCI_BAR*4) & (~0x7);
+ return readb((void*)base + 4*offset);
+ }
if (CONFIG_DEBUG_SERIAL_MMIO) {
ASSERT32FLAT();
return readb((void*)CONFIG_DEBUG_SERIAL_MEM_ADDRESS + 4*offset);
@@ -65,7 +86,9 @@ serial_debug_preinit(void)
static void
serial_debug(char c)
{
- if (!CONFIG_DEBUG_SERIAL && (!CONFIG_DEBUG_SERIAL_MMIO || MODESEGMENT))
+ if (!CONFIG_DEBUG_SERIAL && !CONFIG_DEBUG_SERIAL_PCI_IO &&
+ ((!CONFIG_DEBUG_SERIAL_MMIO && !CONFIG_DEBUG_SERIAL_PCI_MEM32) ||
+ MODESEGMENT))
return;
int timeout = DEBUG_TIMEOUT;
while ((serial_debug_read(SEROFF_LSR) & 0x20) != 0x20)
@@ -87,7 +110,9 @@ serial_debug_putc(char c)
void
serial_debug_flush(void)
{
- if (!CONFIG_DEBUG_SERIAL && (!CONFIG_DEBUG_SERIAL_MMIO || MODESEGMENT))
+ if (!CONFIG_DEBUG_SERIAL && !CONFIG_DEBUG_SERIAL_PCI_IO &&
+ ((!CONFIG_DEBUG_SERIAL_MMIO && !CONFIG_DEBUG_SERIAL_PCI_MEM32) ||
+ MODESEGMENT))
return;
int timeout = DEBUG_TIMEOUT;
while ((serial_debug_read(SEROFF_LSR) & 0x60) != 0x60)
--
2.17.1
From 3bf91481863ec504d113aa6b94827bf92840e291 Mon Sep 17 00:00:00 2001
From: gaobin <gaobin(a)amazon.com>
Date: Thu, 19 Sep 2019 11:23:04 -0700
Subject: [PATCH 2/4] pci: Allow scanning pci bus number up to 255 in CSM mode
On real hardware especially server platforms, there are many pci
devices, bridges, either SoC integrated or addon. They can exhaust
all the pci bus numbers. So when scanning the pci bus, we need to
allow the bus number up to 255.
Signed-off-by: gaobin <gaobin(a)amazon.com>
---
src/hw/pcidevice.c | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/src/hw/pcidevice.c b/src/hw/pcidevice.c
index 8853cf7..acf15b4 100644
--- a/src/hw/pcidevice.c
+++ b/src/hw/pcidevice.c
@@ -26,6 +26,12 @@ pci_probe_devices(void)
struct hlist_node **pprev = &PCIDevices.first;
int extraroots = romfile_loadint("etc/extra-pci-roots", 0);
int bus = -1, lastbus = 0, rootbuses = 0, count=0;
+
+ // On real hardware especially server platforms, the bus number
+ // could run up to the top value, i.e. 0xff
+ if (CONFIG_CSM)
+ extraroots = 0xff;
+
while (bus < 0xff && (bus < MaxPCIBus || rootbuses < extraroots)) {
bus++;
int bdf;
--
2.17.1
Hi,
Almost a year since 1.12.0 was tagged (Nov 17th to be exact),
time to plan the 1.13 release I think ...
How about freeze in a week or two, release by mid-november?
Pending stuff I'm aware of is the disk geometry patch series.
The corresponding qemu series is still waiting to be merged.
There already was a pull request for it though, it only was
dropped due to a regression showing up, so I think there is
still a chance that it'll be merged shortly given that no
objections where raised during review.
Anything else which should be considered for 1.13?
cheers,
Gerd
Hi Michael & Lists,
I'd like to ask for ideas with the following problem we have.
(1) There is a functional iPXE + WDS setup, with iPXE built as a
traditional BIOS PCI option ROM, using CONFIG=qemu. Accordingly the
platform is qemu, with SeaBIOS, and the NIC is virtio-net-pci.
I don't know anything about the particulars of the WDS setup at this
point, only that the boot loader program it exposes is WDSNBP.COM.
(2) The setup works fine when iPXE is built at commit 4e85b2708fa0
("[virtio] Use host-specified MTU when available", 2017-01-23).
(3) When iPXE is built at commit 133f4c47baef ("[build] Handle
R_X86_64_PLT32 from binutils 2.31", 2018-09-17), the setup breaks.
The symptom is that iPXE fetches WDSNBP.COM just fine, but WDSNBP.COM,
rather than doing whatever it does otherwise, keeps PXE-booting itself
(3+ times), and finally aborts.
Consider the following log output (my undertanding is that all this is
logged by WDSNBP.COM):
> Downloaded WDSNBP...
>
> Press F12 for network service boot
> Architecture: x64
> WDSNBP started using DHCP Referral.
> Contacting Server: ... (Gateway: ...)
> Contacting Server: ...
> TFTP Download: boot\x86\wdsnbp.com
This block repeats approx. 3 times, after which the following is
displayed:
> Windows Deployment Services: PXE Boot Aborted.
> Could not boot image: Error 0x7f8d8101 (http://ipxe.org/7f8d8101)
> No more network devices
>
> No bootable device
My understanding is that the first line from this last block is printed
by WDSNBP.COM, the second line by iPXE (in pxe_start_nbp()), the third
line also by iPXE, and the last one by SeaBIOS.
This seems to indicate that WDSNBP.COM exits with an error code, and
pxe_start_nbp() logs it as "Error 0x7f8d8101".
(4) Now, after a bit of searching the web, I've found the following
articles, which indicate that the WDS (= server side) setup is
incorrect:
(4a) "disable NetBios over TCPIP, on the WDS server"
https://techthoughts.info/pxe-booting-wds-dhcp-scope-vs-ip-helpers/#comme...https://social.technet.microsoft.com/Forums/ie/en-US/f3883e8b-1039-477d-9...
(4b) "cover all combinations of forward and backwards slashes in
ReadFilter, on the WDS server"
http://ipxe.org/appnote/chainload_wds#tftp_loops
However: the regression appears to be a function of *only* the git
commit at which we build iPXE. It seems so deterministic that we
bisected commit range 4e85b2708fa0..133f4c47baef. (Hence we have not
captured the network traffic yet, nor have we investigated the WDS
server config.)
The "culprit" commit is ea29122a70c6 ("[http] Include error messages for
4xx and 5xx response codes", 2017-12-28).
(5) Which makes no sense to me, unfortunately. :(
Commit ea29122a70c6 adds the "http_errors" array to the code. According
to
src/include/ipxe/tables.h
and the build artifact
src/bin/1af41000.rom.tmp.map
this new array is placed in a new section called
.textdata.tbl.errortab.01
Trying to retro-fit those facts to the symptom encountered, I came up
with the idea that *maybe* the new array (or section) causes a memory
allocation failure in WDSNBP.COM -- due to increased memory footprint of
iPXE. Which then leads to the misbehavior of WDSNBP.COM.
After all, WDSNBP.COM is a 16-bit real-mode program:
https://support.microsoft.com/en-us/help/4468601/pxe-boot-in-configuratio...
so it could be susceptible to the size & fragmentation of the RAM that
is under 640KB.
(6) Unfortunately, this "low RAM exhaustion" idea doesn't seem to hold
water. There are at least two counter-arguments:
(6a) if I revert commit ea29122a70c6 on top of commit 133f4c47baef, then
the issue does *not* go away.
(The issue also does not go away if I remove the "netdev_errors" array,
also on top of commit 133f4c47baef -- that's a larger array.)
(... In theory anyway, this might not necessarily disprove the memory
exhaustion idea. What if the iPXE footprint grows, over the
ea29122a70c6..133f4c47baef so much, for independent reasons, that
reverting ea29122a70c6 at the end cannot compensate for that increase?)
(6b) I added "DEBUG=pxe_call:1" to the "make" command, and compared the
debug messages printed by pxe_start_nbp(), between 4e85b2708fa0 and
133f4c47baef. Alas, the debug messages are identical:
> PXE NBP starting with netdev net0, code 9c6c:0802, data 9cf0:2ce0
which to me suggests that there is no change in the amount of memory
that is made available to WDSNBP.COM -- its code and data continue to
start at 0x9_CEC2 and 0x9_FBE0, respectively.
Any hints as to what could be going wrong?
Thanks!
Laszlo
This series of patches addresses issues that may arise if a TPM sends
unexpected short packets.
Stefan
Stefan Berger (2):
tpm: Require a response to have minimum size of a valid response
header
tcgbios: Check for enough bytes returned from TPM2_GetCapability
src/hw/tpm_drivers.c | 3 ++-
src/tcgbios.c | 13 +++++++++++--
2 files changed, 13 insertions(+), 3 deletions(-)
--
2.20.1
v1:
* more verbose commit message [Gerd]
---
The goal of the patch is to work around a performance bug in guest
linux kernels.
Old linux kernels has a performance flaw in virtio block device access:
on some frequent disk access patterns, e.g. 1M read, the kernel produces
more block requests than needed. This happens because of virtio seg_max
parameter set to 126 (virtqueue_size - 2) which limits the maximum block
request to 516096 (126 * 4096_PAGE_SIZE) bytes.
Setting seg_max > 126 fixes the issue, however, not all linux kernels
allow that without increasing virtio virtqueue size. The old kernels have
a restriction: virtqueue_size >= seg_max. In case of the restriction
violation the old kernels crash.
The restriction is relaxed in the recent linux kernels (ver >= 4.13) with:
commit 44ed8089e991a60d614abe0ee4b9057a28b364e4
Author: Richard W.M. Jones
Date: Thu Aug 10 17:56:51 2017 +0100
scsi: virtio: Reduce BUG if total_sg > virtqueue size to WARN.
and the recent linux kernels don't crash if total_sg > virtqueue size
allowing to set seg_max to the needed value without virtqueue size
increasing.
To fix the performance flaw in the old linux kernels, it's needed to
increse seg_max to 254, and comply the restriction by setting
virtqueue_size to 256.
This is achievable if seabios can support virtqueue size > 128
which this patch actually does.
Windows kernels don't have virtqueue_size >= seg_max restriction and
isn't affected with this kind of the performance bug.
Signed-off-by: Denis Plotnikov <dplotnikov(a)virtuozzo.com>
---
src/hw/virtio-ring.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/hw/virtio-ring.h b/src/hw/virtio-ring.h
index 8604a01..dccc50d 100644
--- a/src/hw/virtio-ring.h
+++ b/src/hw/virtio-ring.h
@@ -20,7 +20,7 @@
#define VIRTIO_F_VERSION_1 32
#define VIRTIO_F_IOMMU_PLATFORM 33
-#define MAX_QUEUE_NUM (128)
+#define MAX_QUEUE_NUM (256)
#define VRING_DESC_F_NEXT 1
#define VRING_DESC_F_WRITE 2
--
2.17.0
v1:
* more verbose commit message [Gerd]
---
The goal of the patch is to work around a performance bug in guest
linux kernels.
Old linux kernels has a performance flaw in virtio block device access:
on some frequent disk access patterns, e.g. 1M read, the kernel produces
more block requests than needed. This happens because of virtio seg_max
parameter set to 126 (virtqueue_size - 2) which limits the maximum block
request to 516096 (126 * 4096_PAGE_SIZE) bytes.
Setting seg_max > 126 fixes the issue, however, not all linux kernels
allow that without increasing virtio virtqueue size. The old kernels have
a restriction: virtqueue_size >= seg_max. In case of the restriction
violation the old kernels crash.
The restriction is relaxed in the recent linux kernels (ver >= 4.13) with:
commit 44ed8089e991a60d614abe0ee4b9057a28b364e4
Author: Richard W.M. Jones
Date: Thu Aug 10 17:56:51 2017 +0100
scsi: virtio: Reduce BUG if total_sg > virtqueue size to WARN.
and the recent linux kernels don't crash if total_sg > virtqueue size
allowing to set seg_max to the needed value without virtqueue size
increasing.
To fix the performance flaw in the old linux kernels, it's needed to
increse seg_max to 254, and comply the restriction by setting
virtqueue_size to 256.
This is achievable if seabios can support virtqueue size > 128
which this patch actually does.
Windows kernels don't have virtqueue_size >= seg_max restriction and
isn't affected with this kind of the performance bug.
Signed-off-by: Denis Plotnikov <dplotnikov(a)virtuozzo.com>
---
src/hw/virtio-ring.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/hw/virtio-ring.h b/src/hw/virtio-ring.h
index 8604a01..dccc50d 100644
--- a/src/hw/virtio-ring.h
+++ b/src/hw/virtio-ring.h
@@ -20,7 +20,7 @@
#define VIRTIO_F_VERSION_1 32
#define VIRTIO_F_IOMMU_PLATFORM 33
-#define MAX_QUEUE_NUM (128)
+#define MAX_QUEUE_NUM (256)
#define VRING_DESC_F_NEXT 1
#define VRING_DESC_F_WRITE 2
--
2.17.0
