[SeaBIOS] Re: [PATCH] fw/pciinit: don't misalign large BARs
On Wed, Apr 10, 2024 at 11:01:34AM +0300, Daniil Tatianin wrote: > Previously we would unconditionally lower the alignment for large BARs > in case their alignment was greater than "pci_mem64_top >> 11", this > would make it impossible to use these devices by the kernel: > [ 13.821108] pci :9c:00.0: can't claim BAR 1 [mem > 0x660-0x67f 64bit pref]: no compatible bridge window 128G bar. Wow. May I ask what device this is? > +u64 top_align = pci_mem64_top >> 11; > if (hotplug_support && pci_pad_mem64 && is64 > -&& (type == PCI_REGION_TYPE_PREFMEM)) > -align = pci_mem64_top >> 11; > +&& (type == PCI_REGION_TYPE_PREFMEM) && (top_align > align)) > +align = top_align; Makes sense. Reviewed-by: Gerd Hoffmann take care, Gerd ___ SeaBIOS mailing list -- seabios@seabios.org To unsubscribe send an email to seabios-le...@seabios.org
[SeaBIOS] Re: [PATCH 1/2] romfile: implement a generic loader
On Sat, Feb 10, 2024 at 08:39:15PM +, Riku Viitanen via SeaBIOS wrote: > romfile_loadfile_g: > Based on romfile_loadfile but more flexible. User has to supply pointer > to a malloc function and the number of trailing padding bytes. Thus, any > memory region may be used. I'd suggest to add a romfile_loadfile_low(), or add a 'struct zone_s' parameter instead of passing in a function pointer. Also: What the trailing bytes are used for? Patch 2/2 doesn't use that. take care, Gerd ___ SeaBIOS mailing list -- seabios@seabios.org To unsubscribe send an email to seabios-le...@seabios.org
[SeaBIOS] Re: an issue with win10 boot and different compiler versions
On Sun, Feb 11, 2024 at 09:49:21AM +0300, Michael Tokarev wrote: > Hello! Thank you for the reply! > > > Just a random idea, maybe there is something wrong with windows failing to > > emulate stuff? > > (the vgafixup.py) > > Well. > > Windows might fail to emulate something. The prob with that is that we > can't fix this, Well, vgafixup.py exists exactly to workaround emulator bugs (by avoiding problematic instructions). The Xserver with vesa driver goes emulate the vgabios too, and it has bugs, especially when it comes to 32-bit instructions ... So there is a fair chance that we actually can do something about it once we know the root cause. Analyzing that kind of issues is a PITA though, especially with closed source software being involved. > > I would try to boot with non working vgabios something else, like > > grub2, and there I would do: insmod vbe videotest > > This one seems to be working (I had to add `loadfont unicode' before; > I never used grub before so don't know the details here). Booting linux kernels with vga=ask can also serve as simple vgabios test btw. But with both linux and grub running there is no emulator involved, so it is unlikely to help much ... > And the original bug report talks about windows, especially windows 10 - > just tried windows 7, and I don't see this behavior with it. Could very well be that microsoft switched to an emulator in newer versions to sandbox the vgabios. Possibly it's also different in 32-bit vs. 64-bit windows versions. take care, Gerd ___ SeaBIOS mailing list -- seabios@seabios.org To unsubscribe send an email to seabios-le...@seabios.org
[SeaBIOS] Re: an issue with win10 boot and different compiler versions
On Mon, Feb 12, 2024 at 01:06:34PM +0100, Fiona Ebner wrote:
> Am 10.02.24 um 21:17 schrieb Michael Tokarev:
> > So.. the difference is vgabios only, not seabios (vgabios-stdvga in this
> > case).
> >
> > And I can't get it to work with debugging vgabios, it always fails even
> > with DEBUG_LEVEL=2
> > (and level-1 logging isn't useful).
> >
> > I was able to capture logs just for the non-working version, so there's
> > nothing to
> > compare it against. So I tried a different machine type in qemu, the
> > one which
> > works, which uses SMBIOS 3.0 (q35-8.2).
> >
>
>
> Hi,
>
> Windows apparently doesn't read SMBIOS 3.0 tables:
> https://gitlab.com/qemu-project/qemu/-/issues/2008#note_1712210029
>
> Not sure if this is relevant for your issue and it only "works" because
> of that with newer machine models. But it seems worth mentioning.
Note that there is an option to explicitly set the smbios version:
qemu -machine q35,smbios-entry-point-type={32,64}
That will override the machine type default.
take care,
Gerd
___
SeaBIOS mailing list -- seabios@seabios.org
To unsubscribe send an email to seabios-le...@seabios.org
[SeaBIOS] Re: new release tag?
Hi, > > Cc'ing qemu-devel: Are there any qemu changes pending or > > planned for 8.2 which need changes in seabios? /me notes that nobody raised his hand. > Hello Gerd, > > The QEMU 8.2 devel cycle has started. > > I do not want to stress you, but if we want to get additional fixes in, > that depend on the new seabios version, isn't it better to get the new > seabios version included sooner rather than later? Yep. I think I'll go with a git snapshot for now, to give the current seabios master some more testing coverage before tagging a release. take care, Gerd ___ SeaBIOS mailing list -- seabios@seabios.org To unsubscribe send an email to seabios-le...@seabios.org
[SeaBIOS] Re: [PATCH] add multiple usb-hid support
Hi,
> -struct usb_pipe *keyboard_pipe VARFSEG;
> +struct keyboard_list {
> +struct usb_pipe *keyboard_pipe;
> +struct keyboard_list *next;
> +};
seabios has list macros (see src/list.h), please use them to implement a
linked list.
thanks,
Gerd
___
SeaBIOS mailing list -- seabios@seabios.org
To unsubscribe send an email to seabios-le...@seabios.org
[SeaBIOS] Re: [PATCH v4 0/6] misc tweaks for kvm and the 64bit pci window
On Thu, Aug 24, 2023 at 10:57:50AM +0200, Gerd Hoffmann wrote: > v4 changes: > - fix handling of 32bit memory bars. > v3 changes: > - rename variables, use u8 for CPULongMode. > v2 changes: > - e820 conflict fix > > Gerd Hoffmann (6): > better kvm detection > detect physical address space size > move 64bit pci window to end of address space > be less conservative with the 64bit pci io window > qemu: log reservations in fw_cfg e820 table > check for e820 conflict Patch series committed now. take care, Gerd ___ SeaBIOS mailing list -- seabios@seabios.org To unsubscribe send an email to seabios-le...@seabios.org
[SeaBIOS] [PATCH v4 6/6] check for e820 conflict
Add support to check for overlaps with e820 entries.
In case the 64bit pci io window has conflicts move it down.
The only known case where this happens is AMD processors
with 1TB address space which has some space just below
1TB reserved for HT.
Signed-off-by: Gerd Hoffmann
---
src/e820map.h| 1 +
src/e820map.c| 15 +++
src/fw/pciinit.c | 2 ++
3 files changed, 18 insertions(+)
diff --git a/src/e820map.h b/src/e820map.h
index de8b523003c5..07ce16ec213f 100644
--- a/src/e820map.h
+++ b/src/e820map.h
@@ -18,6 +18,7 @@ struct e820entry {
void e820_add(u64 start, u64 size, u32 type);
void e820_remove(u64 start, u64 size);
void e820_prepboot(void);
+int e820_is_used(u64 start, u64 size);
// e820 map storage
extern struct e820entry e820_list[];
diff --git a/src/e820map.c b/src/e820map.c
index 39445cf6399d..c761e5e98a75 100644
--- a/src/e820map.c
+++ b/src/e820map.c
@@ -150,3 +150,18 @@ e820_prepboot(void)
{
dump_map();
}
+
+int
+e820_is_used(u64 start, u64 size)
+{
+int i;
+for (i=0; istart)
+continue;
+if (start >= e->start + e->size)
+continue;
+return 1;
+}
+return 0;
+}
diff --git a/src/fw/pciinit.c b/src/fw/pciinit.c
index b52bd1d5054b..c7084f5e397e 100644
--- a/src/fw/pciinit.c
+++ b/src/fw/pciinit.c
@@ -1140,6 +1140,8 @@ static void pci_bios_map_devices(struct pci_bus *busses)
if (r64_mem.base < top - size) {
r64_mem.base = top - size;
}
+if (e820_is_used(r64_mem.base, size))
+r64_mem.base -= size;
}
r64_mem.base = ALIGN(r64_mem.base, align_mem);
r64_mem.base = ALIGN(r64_mem.base, (1LL<<30));// 1G hugepage
--
2.41.0
___
SeaBIOS mailing list -- seabios@seabios.org
To unsubscribe send an email to seabios-le...@seabios.org
[SeaBIOS] [PATCH v4 5/6] qemu: log reservations in fw_cfg e820 table
With loglevel 1 (same we use for RAM entries),
so it is included in the firmware log by default.
Signed-off-by: Gerd Hoffmann
---
src/fw/paravirt.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/fw/paravirt.c b/src/fw/paravirt.c
index 3aee4c0d4e6b..e5d4eca0cb5a 100644
--- a/src/fw/paravirt.c
+++ b/src/fw/paravirt.c
@@ -765,7 +765,7 @@ static int qemu_early_e820(void)
switch (table.type) {
case E820_RESERVED:
e820_add(table.address, table.length, table.type);
-dprintf(3, "qemu/e820: addr 0x%016llx len 0x%016llx [reserved]\n",
+dprintf(1, "qemu/e820: addr 0x%016llx len 0x%016llx [reserved]\n",
table.address, table.length);
break;
case E820_RAM:
--
2.41.0
___
SeaBIOS mailing list -- seabios@seabios.org
To unsubscribe send an email to seabios-le...@seabios.org
[SeaBIOS] [PATCH v4 4/6] be less conservative with the 64bit pci io window
Current seabios code will only enable and use the 64bit pci io window in
case it runs out of space in the 32bit pci mmio window below 4G.
This patch will also enable the 64bit pci io window when
(a) RAM above 4G is present, and
(b) the physical address space size is known, and
(c) seabios is running on a 64bit capable processor.
This operates with the assumption that guests which are ok with memory
above 4G most likely can handle mmio above 4G too.
In case the 64bit pci io window is enabled also assign more memory to
prefetchable pci bridge windows and the complete 64bit pci io window.
The total mmio window size is 1/8 of the physical address space.
Minimum bridge windows size is 1/256 of the total mmio window size.
Signed-off-by: Gerd Hoffmann
---
src/fw/pciinit.c | 16
1 file changed, 12 insertions(+), 4 deletions(-)
diff --git a/src/fw/pciinit.c b/src/fw/pciinit.c
index 0fcd2be598a2..b52bd1d5054b 100644
--- a/src/fw/pciinit.c
+++ b/src/fw/pciinit.c
@@ -51,6 +51,7 @@ u64 pcimem_end = BUILD_PCIMEM_END;
u64 pcimem64_start = BUILD_PCIMEM64_START;
u64 pcimem64_end = BUILD_PCIMEM64_END;
u64 pci_io_low_end = 0xa000;
+u32 pci_use_64bit = 0;
struct pci_region_entry {
struct pci_device *dev;
@@ -960,10 +961,14 @@ static int pci_bios_check_devices(struct pci_bus *busses)
if (pci_region_align(>r[type]) > align)
align = pci_region_align(>r[type]);
u64 sum = pci_region_sum(>r[type]);
+int is64 = pci_bios_bridge_region_is64(>r[type],
+ s->bus_dev, type);
int resource_optional = 0;
if (hotplug_support == HOTPLUG_PCIE)
resource_optional = pcie_cap && (type == PCI_REGION_TYPE_IO);
-if (!sum && hotplug_support && !resource_optional)
+if (hotplug_support && pci_use_64bit && is64 && (type ==
PCI_REGION_TYPE_PREFMEM))
+align = (u64)1 << (CPUPhysBits - 11);
+if (align > sum && hotplug_support && !resource_optional)
sum = align; /* reserve min size for hot-plug */
if (size > sum) {
dprintf(1, "PCI: QEMU resource reserve cap: "
@@ -975,8 +980,6 @@ static int pci_bios_check_devices(struct pci_bus *busses)
} else {
size = ALIGN(sum, align);
}
-int is64 = pci_bios_bridge_region_is64(>r[type],
-s->bus_dev, type);
// entry->bar is -1 if the entry represents a bridge region
struct pci_region_entry *entry = pci_region_create_entry(
parent, s->bus_dev, -1, size, align, type, is64);
@@ -1108,7 +,7 @@ static void pci_bios_map_devices(struct pci_bus *busses)
panic("PCI: out of I/O address space\n");
dprintf(1, "PCI: 32: %016llx - %016llx\n", pcimem_start, pcimem_end);
-if (pci_bios_init_root_regions_mem(busses)) {
+if (pci_use_64bit || pci_bios_init_root_regions_mem(busses)) {
struct pci_region r64_mem, r64_pref;
r64_mem.list.first = NULL;
r64_pref.list.first = NULL;
@@ -1132,6 +1135,8 @@ static void pci_bios_map_devices(struct pci_bus *busses)
u64 top = 1LL << CPUPhysBits;
u64 size = (ALIGN(sum_mem, (1LL<<30)) +
ALIGN(sum_pref, (1LL<<30)));
+if (pci_use_64bit)
+size = ALIGN(size, (1LL<<(CPUPhysBits-3)));
if (r64_mem.base < top - size) {
r64_mem.base = top - size;
}
@@ -1174,6 +1179,9 @@ pci_setup(void)
dprintf(3, "pci setup\n");
+if (CPUPhysBits >= 36 && CPULongMode && RamSizeOver4G)
+pci_use_64bit = 1;
+
dprintf(1, "=== PCI bus & bridge init ===\n");
if (pci_probe_host() != 0) {
return;
--
2.41.0
___
SeaBIOS mailing list -- seabios@seabios.org
To unsubscribe send an email to seabios-le...@seabios.org
[SeaBIOS] [PATCH v4 2/6] detect physical address space size
Check for pae and long mode using cpuid. If present also read the
physical address bits. Apply some qemu sanity checks (see below).
Record results in PhysBits and LongMode variables. In case we are not
sure what the address space size is leave the PhysBits variable unset.
On qemu we have the problem that for historical reasons x86_64
processors advertise 40 physical address space bits by default, even in
case the host supports less than that so actually using the whole
address space will not work.
Because of that the code applies some extra sanity checks in case we
find 40 (or less) physical address space bits advertised. Only
known-good values (which is 40 for amd processors and 36+39 for intel
processors) will be accepted as valid.
Recommendation is to use 'qemu -cpu ${name},host-phys-bits=on' to
advertise valid physical address space bits to the guest. Some distro
builds enable this by default, and most likely the qemu default will
change in near future too.
Signed-off-by: Gerd Hoffmann
---
src/fw/paravirt.h | 2 ++
src/fw/paravirt.c | 57 +++
2 files changed, 59 insertions(+)
diff --git a/src/fw/paravirt.h b/src/fw/paravirt.h
index 4e2e993ba9d3..62a2cd075d2b 100644
--- a/src/fw/paravirt.h
+++ b/src/fw/paravirt.h
@@ -31,6 +31,8 @@ typedef struct QemuCfgDmaAccess {
extern u32 RamSize;
extern u64 RamSizeOver4G;
extern int PlatformRunningOn;
+extern u8 CPUPhysBits;
+extern u8 CPULongMode;
static inline int runningOnQEMU(void) {
return CONFIG_QEMU || (
diff --git a/src/fw/paravirt.c b/src/fw/paravirt.c
index 42abac8460c5..3aee4c0d4e6b 100644
--- a/src/fw/paravirt.c
+++ b/src/fw/paravirt.c
@@ -32,6 +32,10 @@
u32 RamSize;
// Amount of continuous ram >4Gig
u64 RamSizeOver4G;
+// physical address space bits
+u8 CPUPhysBits;
+// 64bit processor
+u8 CPULongMode;
// Type of emulator platform.
int PlatformRunningOn VARFSEG;
// cfg enabled
@@ -130,6 +134,58 @@ static void kvmclock_init(void)
tsctimer_setfreq(MHz * 1000, "kvmclock");
}
+static void physbits(int qemu_quirk)
+{
+unsigned int max, eax, ebx, ecx, edx;
+unsigned int physbits;
+char signature[13];
+int pae = 0, valid = 0;
+
+cpuid(0, , , , );
+memcpy(signature + 0, , 4);
+memcpy(signature + 4, , 4);
+memcpy(signature + 8, , 4);
+signature[12] = 0;
+if (eax >= 1) {
+cpuid(1, , , , );
+pae = (edx & (1 << 6));
+}
+
+cpuid(0x8000, , , , );
+max = eax;
+
+if (max >= 0x8001) {
+cpuid(0x8001, , , , );
+CPULongMode = !!(edx & (1 << 29));
+}
+
+if (pae && CPULongMode && max >= 0x8008) {
+cpuid(0x8008, , , , );
+physbits = (u8)eax;
+if (!qemu_quirk) {
+valid = 1;
+} else if (physbits >= 41) {
+valid = 1;
+} else if (strcmp(signature, "GenuineIntel") == 0) {
+if ((physbits == 36) || (physbits == 39))
+valid = 1;
+} else if (strcmp(signature, "AuthenticAMD") == 0) {
+if (physbits == 40)
+valid = 1;
+}
+} else {
+physbits = pae ? 36 : 32;
+valid = 1;
+}
+
+dprintf(1, "%s: signature=\"%s\", pae=%s, lm=%s, phys-bits=%d, valid=%s\n",
+__func__, signature, pae ? "yes" : "no", CPULongMode ? "yes" :
"no",
+physbits, valid ? "yes" : "no");
+
+if (valid)
+CPUPhysBits = physbits;
+}
+
static void qemu_detect(void)
{
if (!CONFIG_QEMU_HARDWARE)
@@ -162,6 +218,7 @@ static void qemu_detect(void)
dprintf(1, "Running on QEMU (unknown nb: %04x:%04x)\n", v, d);
break;
}
+physbits(1);
}
static int qemu_early_e820(void);
--
2.41.0
___
SeaBIOS mailing list -- seabios@seabios.org
To unsubscribe send an email to seabios-le...@seabios.org
[SeaBIOS] [PATCH v4 3/6] move 64bit pci window to end of address space
When the size of the physical address space is known (PhysBits is not
zero) move the 64bit pci io window to the end of the address space.
Signed-off-by: Gerd Hoffmann
---
src/fw/pciinit.c | 8
1 file changed, 8 insertions(+)
diff --git a/src/fw/pciinit.c b/src/fw/pciinit.c
index badf13d3233b..0fcd2be598a2 100644
--- a/src/fw/pciinit.c
+++ b/src/fw/pciinit.c
@@ -1128,6 +1128,14 @@ static void pci_bios_map_devices(struct pci_bus *busses)
r64_mem.base = le64_to_cpu(romfile_loadint("etc/reserved-memory-end",
0));
if (r64_mem.base < 0x1LL + RamSizeOver4G)
r64_mem.base = 0x1LL + RamSizeOver4G;
+if (CPUPhysBits) {
+u64 top = 1LL << CPUPhysBits;
+u64 size = (ALIGN(sum_mem, (1LL<<30)) +
+ALIGN(sum_pref, (1LL<<30)));
+if (r64_mem.base < top - size) {
+r64_mem.base = top - size;
+}
+}
r64_mem.base = ALIGN(r64_mem.base, align_mem);
r64_mem.base = ALIGN(r64_mem.base, (1LL<<30));// 1G hugepage
r64_pref.base = r64_mem.base + sum_mem;
--
2.41.0
___
SeaBIOS mailing list -- seabios@seabios.org
To unsubscribe send an email to seabios-le...@seabios.org
[SeaBIOS] [PATCH v4 0/6] misc tweaks for kvm and the 64bit pci window
v4 changes: - fix handling of 32bit memory bars. v3 changes: - rename variables, use u8 for CPULongMode. v2 changes: - e820 conflict fix Gerd Hoffmann (6): better kvm detection detect physical address space size move 64bit pci window to end of address space be less conservative with the 64bit pci io window qemu: log reservations in fw_cfg e820 table check for e820 conflict src/e820map.h | 1 + src/fw/paravirt.h | 2 ++ src/e820map.c | 15 src/fw/paravirt.c | 89 +-- src/fw/pciinit.c | 26 +++--- 5 files changed, 119 insertions(+), 14 deletions(-) -- 2.41.0 ___ SeaBIOS mailing list -- seabios@seabios.org To unsubscribe send an email to seabios-le...@seabios.org
[SeaBIOS] [PATCH v4 1/6] better kvm detection
In case kvm emulates features of another hypervisor (for example hyperv)
two VMM CPUID blocks will be present, one for the emulated hypervisor
and one for kvm itself.
This patch makes seabios loop over the VMM CPUID blocks to make sure it
will properly detect kvm when multiple blocks are present.
Signed-off-by: Gerd Hoffmann
---
src/fw/paravirt.c | 30 +-
1 file changed, 21 insertions(+), 9 deletions(-)
diff --git a/src/fw/paravirt.c b/src/fw/paravirt.c
index fba4e52db684..42abac8460c5 100644
--- a/src/fw/paravirt.c
+++ b/src/fw/paravirt.c
@@ -53,23 +53,35 @@ inline int qemu_cfg_dma_enabled(void)
* should be used to determine that a VM is running under KVM.
*/
#define KVM_CPUID_SIGNATURE 0x4000
+static unsigned int kvm_cpuid_base = 0;
static void kvm_detect(void)
{
+unsigned int i, max = 0;
unsigned int eax, ebx, ecx, edx;
char signature[13];
-cpuid(KVM_CPUID_SIGNATURE, , , , );
-memcpy(signature + 0, , 4);
-memcpy(signature + 4, , 4);
-memcpy(signature + 8, , 4);
-signature[12] = 0;
+for (i = KVM_CPUID_SIGNATURE;; i += 0x100) {
+eax = 0;
+cpuid(i, , , , );
+if (eax < i)
+break;
+memcpy(signature + 0, , 4);
+memcpy(signature + 4, , 4);
+memcpy(signature + 8, , 4);
+signature[12] = 0;
+dprintf(1, "cpuid 0x%x: eax %x, signature '%s'\n", i, eax, signature);
+if (strcmp(signature, "KVMKVMKVM") == 0) {
+kvm_cpuid_base = i;
+max = eax;
+}
+}
-if (strcmp(signature, "KVMKVMKVM") == 0) {
+if (kvm_cpuid_base) {
dprintf(1, "Running on KVM\n");
PlatformRunningOn |= PF_KVM;
-if (eax >= KVM_CPUID_SIGNATURE + 0x10) {
-cpuid(KVM_CPUID_SIGNATURE + 0x10, , , , );
+if (max >= kvm_cpuid_base + 0x10) {
+cpuid(kvm_cpuid_base + 0x10, , , , );
dprintf(1, "kvm: have invtsc, freq %u kHz\n", eax);
tsctimer_setfreq(eax, "invtsc");
}
@@ -93,7 +105,7 @@ static void kvmclock_init(void)
if (!runningOnKVM())
return;
-cpuid(KVM_CPUID_SIGNATURE + 0x01, , , , );
+cpuid(kvm_cpuid_base + 0x01, , , , );
if (eax & (1 << KVM_FEATURE_CLOCKSOURCE2))
msr = MSR_KVM_SYSTEM_TIME_NEW;
else if (eax & (1 << KVM_FEATURE_CLOCKSOURCE))
--
2.41.0
___
SeaBIOS mailing list -- seabios@seabios.org
To unsubscribe send an email to seabios-le...@seabios.org
[SeaBIOS] Re: new release tag?
On Mon, Aug 07, 2023 at 10:51:33AM +, Niklas Cassel via SeaBIOS wrote: > Hello Seabios maintainers, > > > I was wondering, is there any chance of getting a new release tag > (e.g. rel-1.16.3) anytime soon? > Or is there any plan on when it will be tagged? > > I'm waiting to send out a (AHCI specific) QEMU patch, but I can't > do so until: > 1) there is a new Seabios tag > 2) QEMU has updated to the latest Seabios release tag I guess Mark (Cc'ed) is sitting in the same boat with the scsi driver fixes. We just missed qemu 8.1, so we don't have to rush things, but it probably makes sense to update seabios not too late in the 8.2 devel cycle due to qemu patches depending on the seabios fixes. Cc'ing qemu-devel: Are there any qemu changes pending or planned for 8.2 which need changes in seabios? take care, Gerd ___ SeaBIOS mailing list -- seabios@seabios.org To unsubscribe send an email to seabios-le...@seabios.org
[SeaBIOS] Re: [PATCH v3 0/3] esp-scsi: fix reliance on QEMU ESP SCSI implementation bugs
On Mon, Aug 07, 2023 at 07:52:57AM +0100, Mark Cave-Ayland wrote: > Whilst trying to improve QEMU's ESP SCSI implementation with regard to the > NCR datasheet, I noticed that SeaBIOS would fail to boot one of my Debian > test images with my patches applied. > > Further investigation revealed that the SeaBIOS esp-scsi driver inadvertently > relies on existing bugs in QEMU's ESP SCSI emulation to work correctly, so > this > series changes the driver to work as described in the NCR datasheet. > > With this series applied it is possible for the updated SeaBIOS to boot both > QEMU current git HEAD as well as my local WIP branch containing various fixes > and improvements to QEMU's ESP SCSI emulation. > > Signed-off-by: Mark Cave-Ayland Series committed. thanks, Gerd ___ SeaBIOS mailing list -- seabios@seabios.org To unsubscribe send an email to seabios-le...@seabios.org
[SeaBIOS] Re: [Increase BUILD_MAX_E820 to 128] Increase BUILD_MAX_E820 to 128
On Fri, Jul 28, 2023 at 04:41:48AM +, Tony Titus via SeaBIOS wrote: > For platforms with high number of numa nodes, 32 e820 entries are not > enough. Linux kernel sets the maximum e820 entries to a base value of > 128. Setting BUILD_MAX_E820 to 128 to be in sync with this base value. > > Signed-off-by: Tony Titus Patch committed. thanks, Gerd ___ SeaBIOS mailing list -- seabios@seabios.org To unsubscribe send an email to seabios-le...@seabios.org
[SeaBIOS] Re: [PATCH] ahci: handle TFES irq correctly
On Tue, Jun 13, 2023 at 11:13:29AM -0400, Kevin O'Connor wrote: > On Tue, May 30, 2023 at 03:44:05PM +0200, Niklas Cassel via SeaBIOS wrote: > > According to AHCI 1.3.1, 5.3.8.1 RegFIS:Entry, if ERR_STAT is set in the > > received FIS, the HBA shall jump to state ERR:FatalTaskfile, which will > > raise a TFES IRQ. > > > > This means that if ERR_STAT is set in the recevied FIS, PxIS.TFES will > > be set, without either PxIS.DHRS or PxIS.PSS being set. > > > > SeaBIOS function ahci_port_setup() will try to identify an AHCI device > > by sending an ATAPI identify device command. However, such a command > > will be aborted with ERR_STAT set for a regular (non-ATAPI) device. > > > > ahci_command() already performs the correct error recovery steps when > > status is correctly set, so simply modify ahci_command() to read the > > correct status when PxIS.TFES is set. > > > > It is safe to read PxTFD when PxIS.TFES is set, even for systems with a > > port multiplier, see AHCI 1.3.1, 9.3.7 PxTFD Register Information: > > "When a taskfile error occurs (PxIS.TFES is set to '1'), the host may > > refer to the values in PxTFD. The values in PxTFD at this time are > > guaranteed to correspond to the device that reported the taskfile error > > condition." > > > > Without this, each boot will be delayed by 32 seconds, waiting for the > > AHCI command to timeout. > > Gerd, would you be able to review this patch? Description and patch look good to me, testing with qemu works fine. Tested-by: Gerd Hoffmann Acked-by: Gerd Hoffmann take care, Gerd ___ SeaBIOS mailing list -- seabios@seabios.org To unsubscribe send an email to seabios-le...@seabios.org
[SeaBIOS] Re: Large 32 bit BAR's
Hi, > I'm running a x86 QEMU with Ubuntu. On this system we want to emulate > a PCIe device which contains a large 32-bit BAR (2 GiB). This is not > working and I get following error: Why a 32-bit bar, not a 64-bit bar? A 2G 32-bit bar simply can't be mapped anywhere on x86. It must be below 4G, and it must be 2G-aligned. Which leaves exactly two options: 0G -> 2G or 2G -> 4G. Both overlap with resources critical for x86 boot, the former with the real mode address space (0-1M) and the latter with lapic, ioapic, hpet, tpm etc just below 4G. take care, Gerd ___ SeaBIOS mailing list -- seabios@seabios.org To unsubscribe send an email to seabios-le...@seabios.org
[SeaBIOS] seabios 1.16.2 release tagged (was: Re: Re: [SeaBIOS PATCH] xen: require Xen info structure at). 0x1000 to detect Xen
Hi, > Ok, we have as of today two changes: > > kraxel@sirius ~/projects/seabios (master)# git log --oneline rel-1.16.1.. > ea1b7a073390 xen: require Xen info structure at 0x1000 to detect Xen > 645a64b4911d usb: fix wrong init of keyboard/mouse's if first interface is > not boot protocol > > With no changes since January and no known issues. > I think we can safely tag the current state as 1.16.2. > > I'll do that next monday (plus qemu pull request) unless > there are objections until then. Oops, totally forgot it. Three days after the deadline, still no objections raised, so I tagged the release today and uploaded the source tarball. qemu pull request for the update is out of the door too. take care, Gerd ___ SeaBIOS mailing list -- seabios@seabios.org To unsubscribe send an email to seabios-le...@seabios.org
[SeaBIOS] Re: [SeaBIOS PATCH] xen: require Xen info structure at 0x1000 to detect Xen
On Tue, Mar 07, 2023 at 08:42:18AM +, David Woodhouse wrote: > On Thu, 2023-02-02 at 10:10 +0100, Gerd Hoffmann wrote: > > > Thanks, Kevin. > > > > > > I'd like to get the rest of the Xen platform support in to qemu 8.0 > > > if > > > possible. Which is currently scheduled for March. > > > > > > Is there likely to be a SeaBIOS release before then which Gerd > > > would > > > pull into qemu anyway, or should I submit a submodule update to a > > > snapshot of today's tree? That would just pull in this commit, and > > > the > > > one other fix that's in the SeaBIOS tree since 1.16.1? > > > > Tagging 1.16.2 in time for the qemu 8.0 should not be a problem given > > that we have only bugfixes in master. Roughly around soft freeze is > > probably a good time for that. > > That's, erm, at the *end* of today 2023-03-07, and the freeze happens > only *after* Paul has reviewed the phase 2 Xen PV back end support, > right? Ok, we have as of today two changes: kraxel@sirius ~/projects/seabios (master)# git log --oneline rel-1.16.1.. ea1b7a073390 xen: require Xen info structure at 0x1000 to detect Xen 645a64b4911d usb: fix wrong init of keyboard/mouse's if first interface is not boot protocol With no changes since January and no known issues. I think we can safely tag the current state as 1.16.2. I'll do that next monday (plus qemu pull request) unless there are objections until then. take care, Gerd ___ SeaBIOS mailing list -- seabios@seabios.org To unsubscribe send an email to seabios-le...@seabios.org
[SeaBIOS] Re: SeaBIOS 1.16.1 release
On Tue, Jan 24, 2023 at 12:58:26PM +0100, Marek Marczykowski-Górecki wrote: > Hello, > > I see rel-1.16.1 tag on > https://review.coreboot.org/plugins/gitiles/seabios/, but that's about > the only place where it's visible - no tarball, no info on > https://www.seabios.org/Releases etc. Is 1.16.1 an actual release? Yes. Not sure how to upload a relase tarball, last time I did that in 2017 (for 1.10.x) we had a different process I think. Kevin? For the time being you can git-checking out the release tag, then run scripts/tarball.sh to get a release tarball. take care, Gerd ___ SeaBIOS mailing list -- seabios@seabios.org To unsubscribe send an email to seabios-le...@seabios.org
[SeaBIOS] Re: [SeaBIOS PATCH] xen: require Xen info structure at 0x1000 to detect Xen
> Thanks, Kevin. > > I'd like to get the rest of the Xen platform support in to qemu 8.0 if > possible. Which is currently scheduled for March. > > Is there likely to be a SeaBIOS release before then which Gerd would > pull into qemu anyway, or should I submit a submodule update to a > snapshot of today's tree? That would just pull in this commit, and the > one other fix that's in the SeaBIOS tree since 1.16.1? Tagging 1.16.2 in time for the qemu 8.0 should not be a problem given that we have only bugfixes in master. Roughly around soft freeze is probably a good time for that. take care, Gerd ___ SeaBIOS mailing list -- seabios@seabios.org To unsubscribe send an email to seabios-le...@seabios.org
[SeaBIOS] Re: [RFC] PCIe-related MTRR inconsistency on Q35
On Wed, Sep 28, 2022 at 10:56:34AM -0500, Alex Olson wrote:
> Under SeaBIOS, I'm noticing that not all of the PCIe-related area is marked
> uncachable in the MTRR settings, at least in the Q35 platform (QEMU).
>
> I feel like this is a bug, but I'm not familar with the lore behind Q35 and
> MTRRs, feedback would be appreciated.
>
> The MCFG table contains an entry starting at Q35_HOST_BRIDGE_PCIEXBAR_ADDR
> (0xb000) corresponding to a 256MB area. Later, the mch_mem_addr_setup()
> routine defines the PCIe window (pcimem_start) starting at 0xc000
> (Q35_HOST_BRIDGE_PCIEXBAR_ADDR + Q35_HOST_BRIDGE_PCIEXBAR_SIZE).
>
> I see in mtrr_setup(), that only a single variable MTRR is configured based
> solely on pcimem_start and extends to the end of the 4GB boundary. It looks
> to
> me that this is probably fine for 440fx, but seems insufficient for Q35.
>
> Q35 - original SeaBIOS 1.15.0:
> # cat /proc/mtrr
> reg00: base=0x0c000 ( 3072MB), size= 1024MB, count=1: uncachable
>
>
> Q35 - original EFI (ovmf 2202.02)
> # cat /proc/mtrr
> reg00: base=0x0c000 ( 3072MB), size= 1024MB, count=1: uncachable
> reg01: base=0x0b000 ( 2816MB), size= 256MB, count=1: uncachable
> reg02: base=0x8 (32768MB), size=32768MB, count=1: uncachable
See also
https://github.com/tianocore/edk2/commit/2a0bd3bffc80d1982cf85cdad066f79a2f60c769
> Thus, for Q35, there is no explict attempt to configure the
> Q35_HOST_BRIDGE_PCIEXBAR_ADDR area nor any potential the >4GB area used for
> PCIe
> I/O. The inherent size restrictions on MTRR mask definitions make a
> completely
> generic solution a bit tricky.
qemu using gigabyte pages these days should simplify things. If there
is 2G (or less) of low memory mark 2G -> 4G uncachable. If there is 3G
(or less) of low memory mark 3G -> 4G uncachable. Doable with a single
mtrr register, should cover 99% of the use cases and is a improvement
over the current situation.
> I believe solves the issue, but I'm not sure how to test it with a
> 64-bit PCIe window.
Patch the code to force it.
seabios places everything below 4G if it fits, for backward
compatibility reasons. Could be we are booting a 32bit guest OS which
might not be able to deal with PCI bars mapped above 4G ...
Maybe it makes sense to relax that a bit. In case we find memory above
4G it should be safe to assume that PCI bars above 4G are fine too.
take care,
Gerd
commit c7074250e6faaeffc5e8966a8a0ecdfe8a5c2af3
Author: Gerd Hoffmann
Date: Fri Sep 9 10:17:15 2022 +0200
[testing] force 64bit pci window
diff --git a/src/fw/pciinit.c b/src/fw/pciinit.c
index ad6def93633b..08339da2905c 100644
--- a/src/fw/pciinit.c
+++ b/src/fw/pciinit.c
@@ -1108,7 +1108,7 @@ static void pci_bios_map_devices(struct pci_bus *busses)
panic("PCI: out of I/O address space\n");
dprintf(1, "PCI: 32: %016llx - %016llx\n", pcimem_start, pcimem_end);
-if (pci_bios_init_root_regions_mem(busses)) {
+if (1 || pci_bios_init_root_regions_mem(busses)) {
struct pci_region r64_mem, r64_pref;
r64_mem.list.first = NULL;
r64_pref.list.first = NULL;
___
SeaBIOS mailing list -- seabios@seabios.org
To unsubscribe send an email to seabios-le...@seabios.org
[SeaBIOS] Re: [PATCH] virtio-blk: use larger default request size
On Thu, Jul 07, 2022 at 11:13:52AM -0400, Kevin O'Connor wrote: > On Thu, Jul 07, 2022 at 12:06:16PM +0200, Gerd Hoffmann wrote: > > Bump default from 8 to 64 blocks. Using 8 by default leads > > to requests being splitted on qemu, which slows down boot. > > > > Some (temporary) debug logging added showed that almost all > > requests on a standard fedora install are less than 64 blocks, > > so that should bring us back to 1.15 performance levels. > > Thanks. Looks fine to me. Pushed now. take care, Gerd ___ SeaBIOS mailing list -- seabios@seabios.org To unsubscribe send an email to seabios-le...@seabios.org
[SeaBIOS] [PATCH] virtio-blk: use larger default request size
Bump default from 8 to 64 blocks. Using 8 by default leads
to requests being splitted on qemu, which slows down boot.
Some (temporary) debug logging added showed that almost all
requests on a standard fedora install are less than 64 blocks,
so that should bring us back to 1.15 performance levels.
Signed-off-by: Gerd Hoffmann
---
src/hw/virtio-blk.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/hw/virtio-blk.c b/src/hw/virtio-blk.c
index 929ba8873dc0..9b4a05a4c424 100644
--- a/src/hw/virtio-blk.c
+++ b/src/hw/virtio-blk.c
@@ -95,7 +95,7 @@ virtio_blk_op(struct disk_op_s *op, int write)
blk_num_max = (u16)max_io_size / vdrive->drive.blksize;
else
/* default blk_num_max if hardware doesnot advise a proper value */
-blk_num_max = 8;
+blk_num_max = 64;
if (op->count <= blk_num_max) {
virtio_blk_op_one_segment(vdrive, write, sg);
--
2.36.1
___
SeaBIOS mailing list -- seabios@seabios.org
To unsubscribe send an email to seabios-le...@seabios.org
[SeaBIOS] Re: Force 1024x768 resolution on SeaBIOS with coreboot native graphics
On Thu, Jun 30, 2022 at 12:46:39PM -0400, Felix Freeman via SeaBIOS wrote: > On Thu Jun 30, 2022 at 7:29 AM -04, Gerd Hoffmann wrote: > > > So, my first question is: what is needed to force SeaBIOS/SeaVGABIOS > > > to display a resolution of 1024x768 instead of 640x480 when in "text > > > mode" and "video mode"? > > > > Sure, it's possible to filter the list of modes, but that doesn't > > guarantee the software using the vgabios behaves accordingly ... > > Could you give some pointers on how to do that? Is there a hard-coded > selector for the default 640x480 mode? Probably it's hardcoded somewhere (not seabios) with the expectation that it is a safe fallback and works on all devices. > or you mean that I should simply > delete the modes I don't want to use? Simply deleting should be easiest for creating a test build to see whenever it has the desired effect or not. take care, Gerd ___ SeaBIOS mailing list -- seabios@seabios.org To unsubscribe send an email to seabios-le...@seabios.org
[SeaBIOS] Re: Force 1024x768 resolution on SeaBIOS with coreboot native graphics
On Wed, Jun 29, 2022 at 02:50:10AM -0400, Felix Freeman via SeaBIOS wrote:
> Hello,
>
> I have noticed several problems when using coreboot native graphics ("high
> resolution" linear framebuffer) with a resolution of 1024x768, on SeaBIOS +
> SeaVGABIOS:
>
> - Boot menus (GRUB, Syslinux) look at a resolution of 640x480.
> - I get a warning in Debian "graphical" installer "Undefined video mode
> number: 314", asking me to select a mode, if I select a resolution of
> 1024x768 it boots fine, if I don't, after 30 seconds, it crashes.
> - When I use iPXE with SeaBIOS I can't get video on "text based installers"
> (which use ncurses, for example Debian text based installers).
> I don't know if its implementation is incomplete, or because of technical
> reasons SeaVGABIOS is unable to behave correctly without a proprietary VGA
> BIOS.
>
> I think a first step might be to be able to force a minimum resolution in
> text and video modes.
>
> So, my first question is: what is needed to force SeaBIOS/SeaVGABIOS to
> display a resolution of 1024x768 instead of 640x480 when in "text mode" and
> "video mode"?
Sure, it's possible to filter the list of modes, but that doesn't
guarantee the software using the vgabios behaves accordingly ...
debian complaining about 314 missing is such a case. IIRC that is a 15
or 16 bpp mode which is simply not supported in case coreboot native
graphics run with 32 bpp. Seems the debian installer expects that mode
being supported and can't deal with the case that it isn't.
> And my second question is whether with some work the coreboot native graphics
> implementation could behave as good as (or close to) a proprietary VGA BIOS.
Nope. The linear framebuffer has a fixed resolution and depth. That
implies some compatibility constrains which can hardly be avoided.
Also note that text mode emulation on the framebuffer only works for
vgabios calls, linux vgacon (which talks directly to the hardware) is
not supported.
take care,
Gerd
___
SeaBIOS mailing list -- seabios@seabios.org
To unsubscribe send an email to seabios-le...@seabios.org
[SeaBIOS] Re: [SeaVGABIOS] No VBE modes for card on PCIe Root Port
On Tue, Jun 07, 2022 at 09:37:21AM -0600, Kevin Locke wrote: > Hi All, > > With QEMU 7.0.0 and SeaBIOS 1.16.0, virtual machines with a PCIe > graphics card connected to a PCIe Root Port, rather than the Root > Complex, as recommended by the QEMU PCI Express Guidelines[1], are > unable to use VESA BIOS Extensions display modes. For example, > Am I correct in assuming this is a limitation of SeaVGABIOS? Well, sort of. There are two ways to reach the registers needed for the extended display modes, via ioports 0x01ce,0x01cf or via mmio bar (see docs/specs/standard-vga.txt in qemu source tree). The ioport access is not forwarded over pci(e) bridges, the special exception bit for vga register access applies to the classic vga registers only not the vbe registers. vgabios functions must be able to run in real mode, so it uses the ioports, because they are easily reachable. ovmf driver runs in 32bit or 64bit anyway, so using the mmio bar is no problem and the driver prefers that if available. Therefore it is possible to plug vga devices into a pcie root port (although I think it doesn't work for qxl due to mmio bar not being available there). > If it's unlikely to change soon, would > it make sense for me to propose documenting this limitation in the > QEMU PCI Express Guidelines? Yes, it makes sense to add an exception note there. VGA devices should be placed on the root bus to make sure they are fully functional (libvirt does that by default btw). When using UEFI it is possible to pick a device without vga compatibility (i.e. bochs-display or virtio-gpu-pci). The legacy vga stuff (text mode and lowres graphics) wouldn't be used anyway ... take care, Gerd ___ SeaBIOS mailing list -- seabios@seabios.org To unsubscribe send an email to seabios-le...@seabios.org
[SeaBIOS] Re: [PATCH v4 0/2] use large ZoneHigh when there is enough memory
On Wed, Apr 27, 2022 at 10:24:16AM -0400, Kevin O'Connor wrote: > On Wed, Apr 27, 2022 at 09:22:02AM +0200, Gerd Hoffmann wrote: > > v4: > > - make calculations more robust. > > > > v3: > > - check size instead of end address. > > The series looks good to me. Patches pushed now. take care, Gerd ___ SeaBIOS mailing list -- seabios@seabios.org To unsubscribe send an email to seabios-le...@seabios.org
[SeaBIOS] Re: [PATCH v3 2/2] malloc: use large ZoneHigh when there is enough memory
Hi, > I do think your new v4 version of the code is easier to understand > though. Great, that was precisely the point of doing a v4 ;) take care, Gerd ___ SeaBIOS mailing list -- seabios@seabios.org To unsubscribe send an email to seabios-le...@seabios.org
[SeaBIOS] [PATCH v4 2/2] malloc: use large ZoneHigh when there is enough memory
In case there is enough memory installed use a large ZoneHigh.
Signed-off-by: Gerd Hoffmann
---
src/config.h | 3 ++-
src/malloc.c | 14 +-
2 files changed, 11 insertions(+), 6 deletions(-)
diff --git a/src/config.h b/src/config.h
index 93c8dbc2d530..9abe355b6c47 100644
--- a/src/config.h
+++ b/src/config.h
@@ -17,7 +17,8 @@
// Maximum number of map entries in the e820 map
#define BUILD_MAX_E820 32
// Space to reserve in high-memory for tables
-#define BUILD_MAX_HIGHTABLE (256*1024)
+#define BUILD_MIN_HIGHTABLE (256*1024)
+#define BUILD_MAX_HIGHTABLE (16*1024*1024)
// Largest supported externaly facing drive id
#define BUILD_MAX_EXTDRIVE 16
// Number of bytes the smbios may be and still live in the f-segment
diff --git a/src/malloc.c b/src/malloc.c
index ecd8c9ac78d2..da84098005f7 100644
--- a/src/malloc.c
+++ b/src/malloc.c
@@ -423,7 +423,7 @@ malloc_preinit(void)
// Populate temp high ram
u32 highram_start = 0;
-u32 highram_size = BUILD_MAX_HIGHTABLE;
+u32 highram_size = 0;
int i;
for (i=e820_count-1; i>=0; i--) {
struct e820entry *en = _list[i];
@@ -434,10 +434,14 @@ malloc_preinit(void)
continue;
u32 s = en->start, e = end;
if (!highram_start) {
-u32 newe = ALIGN_DOWN(e - highram_size, MALLOC_MIN_ALIGN);
-if (newe <= e && newe >= s) {
-highram_start = newe;
-e = newe;
+u32 new_max = ALIGN_DOWN(e - BUILD_MAX_HIGHTABLE,
MALLOC_MIN_ALIGN);
+u32 new_min = ALIGN_DOWN(e - BUILD_MIN_HIGHTABLE,
MALLOC_MIN_ALIGN);
+if (new_max <= e && new_max >= s + BUILD_MAX_HIGHTABLE) {
+highram_start = e = new_max;
+highram_size = BUILD_MAX_HIGHTABLE;
+} else if (new_min <= e && new_min >= s) {
+highram_start = e = new_min;
+highram_size = BUILD_MIN_HIGHTABLE;
}
}
alloc_add(, s, e);
--
2.35.1
___
SeaBIOS mailing list -- seabios@seabios.org
To unsubscribe send an email to seabios-le...@seabios.org
[SeaBIOS] [PATCH v4 1/2] malloc: use variable for ZoneHigh size
Use the variable highram_size instead of the BUILD_MAX_HIGHTABLE #define
for the ZoneHigh size. Initialize the new variable with the old #define,
so behavior does not change.
This allows to easily adjust the ZoneHigh size at runtime in a followup
patch.
Signed-off-by: Gerd Hoffmann
---
src/malloc.c | 15 ---
1 file changed, 8 insertions(+), 7 deletions(-)
diff --git a/src/malloc.c b/src/malloc.c
index 3733855caf2c..ecd8c9ac78d2 100644
--- a/src/malloc.c
+++ b/src/malloc.c
@@ -422,7 +422,8 @@ malloc_preinit(void)
e820_add(BUILD_BIOS_ADDR, BUILD_BIOS_SIZE, E820_RESERVED);
// Populate temp high ram
-u32 highram = 0;
+u32 highram_start = 0;
+u32 highram_size = BUILD_MAX_HIGHTABLE;
int i;
for (i=e820_count-1; i>=0; i--) {
struct e820entry *en = _list[i];
@@ -432,10 +433,10 @@ malloc_preinit(void)
if (en->type != E820_RAM || end > 0x)
continue;
u32 s = en->start, e = end;
-if (!highram) {
-u32 newe = ALIGN_DOWN(e - BUILD_MAX_HIGHTABLE, MALLOC_MIN_ALIGN);
+if (!highram_start) {
+u32 newe = ALIGN_DOWN(e - highram_size, MALLOC_MIN_ALIGN);
if (newe <= e && newe >= s) {
-highram = newe;
+highram_start = newe;
e = newe;
}
}
@@ -444,9 +445,9 @@ malloc_preinit(void)
// Populate regions
alloc_add(, BUILD_STACK_ADDR, BUILD_EBDA_MINIMUM);
-if (highram) {
-alloc_add(, highram, highram + BUILD_MAX_HIGHTABLE);
-e820_add(highram, BUILD_MAX_HIGHTABLE, E820_RESERVED);
+if (highram_start) {
+alloc_add(, highram_start, highram_start + highram_size);
+e820_add(highram_start, highram_size, E820_RESERVED);
}
}
--
2.35.1
___
SeaBIOS mailing list -- seabios@seabios.org
To unsubscribe send an email to seabios-le...@seabios.org
[SeaBIOS] [PATCH v4 0/2] use large ZoneHigh when there is enough memory
v4: - make calculations more robust. v3: - check size instead of end address. Gerd Hoffmann (2): malloc: use variable for ZoneHigh size malloc: use large ZoneHigh when there is enough memory src/config.h | 3 ++- src/malloc.c | 23 ++- 2 files changed, 16 insertions(+), 10 deletions(-) -- 2.35.1 ___ SeaBIOS mailing list -- seabios@seabios.org To unsubscribe send an email to seabios-le...@seabios.org
[SeaBIOS] Re: [PATCH v3 2/2] malloc: use large ZoneHigh when there is enough memory
> > if (!highram_start) {
> > +if (e - s > BUILD_MAX_HIGHTABLE * 16)
> > +highram_size = BUILD_MAX_HIGHTABLE;
> > u32 newe = ALIGN_DOWN(e - highram_size, MALLOC_MIN_ALIGN);
> > if (newe <= e && newe >= s) {
> > highram_start = newe;
>
> Thanks, but I'm still seeing a corner case where this fails - if
> ALIGN_DOWN() falls below s.
Given that the code requires the memory block being 16x the size of the
zonehigh allocation (i.e. use 16M in case the block is 256M or larger)
I fail to see how any reasonable alignment requirement can make that
fail ...
take care,
Gerd
___
SeaBIOS mailing list -- seabios@seabios.org
To unsubscribe send an email to seabios-le...@seabios.org
[SeaBIOS] [PATCH v3 1/2] malloc: use variable for ZoneHigh size
Use the variable highram_size instead of the BUILD_MAX_HIGHTABLE #define
for the ZoneHigh size. Initialize the new variable with the old #define,
so behavior does not change.
This allows to easily adjust the ZoneHigh size at runtime in a followup
patch.
Signed-off-by: Gerd Hoffmann
---
src/malloc.c | 16 +---
1 file changed, 9 insertions(+), 7 deletions(-)
diff --git a/src/malloc.c b/src/malloc.c
index 3733855caf2c..7fa50a85595b 100644
--- a/src/malloc.c
+++ b/src/malloc.c
@@ -422,7 +422,8 @@ malloc_preinit(void)
e820_add(BUILD_BIOS_ADDR, BUILD_BIOS_SIZE, E820_RESERVED);
// Populate temp high ram
-u32 highram = 0;
+u32 highram_start = 0;
+u32 highram_size = BUILD_MAX_HIGHTABLE;
int i;
for (i=e820_count-1; i>=0; i--) {
struct e820entry *en = _list[i];
@@ -432,10 +433,10 @@ malloc_preinit(void)
if (en->type != E820_RAM || end > 0x)
continue;
u32 s = en->start, e = end;
-if (!highram) {
-u32 newe = ALIGN_DOWN(e - BUILD_MAX_HIGHTABLE, MALLOC_MIN_ALIGN);
+if (!highram_start) {
+u32 newe = ALIGN_DOWN(e - highram_size, MALLOC_MIN_ALIGN);
if (newe <= e && newe >= s) {
-highram = newe;
+highram_start = newe;
e = newe;
}
}
@@ -444,9 +445,10 @@ malloc_preinit(void)
// Populate regions
alloc_add(, BUILD_STACK_ADDR, BUILD_EBDA_MINIMUM);
-if (highram) {
-alloc_add(, highram, highram + BUILD_MAX_HIGHTABLE);
-e820_add(highram, BUILD_MAX_HIGHTABLE, E820_RESERVED);
+if (highram_start) {
+dprintf(3, "malloc: using %dk for ZoneHigh\n", highram_size / 1024);
+alloc_add(, highram_start, highram_start + highram_size);
+e820_add(highram_start, highram_size, E820_RESERVED);
}
}
--
2.35.1
___
SeaBIOS mailing list -- seabios@seabios.org
To unsubscribe send an email to seabios-le...@seabios.org
[SeaBIOS] [PATCH v3 2/2] malloc: use large ZoneHigh when there is enough memory
In case there is enough memory installed use a large ZoneHigh.
Signed-off-by: Gerd Hoffmann
---
src/config.h | 3 ++-
src/malloc.c | 4 +++-
2 files changed, 5 insertions(+), 2 deletions(-)
diff --git a/src/config.h b/src/config.h
index 93c8dbc2d530..9abe355b6c47 100644
--- a/src/config.h
+++ b/src/config.h
@@ -17,7 +17,8 @@
// Maximum number of map entries in the e820 map
#define BUILD_MAX_E820 32
// Space to reserve in high-memory for tables
-#define BUILD_MAX_HIGHTABLE (256*1024)
+#define BUILD_MIN_HIGHTABLE (256*1024)
+#define BUILD_MAX_HIGHTABLE (16*1024*1024)
// Largest supported externaly facing drive id
#define BUILD_MAX_EXTDRIVE 16
// Number of bytes the smbios may be and still live in the f-segment
diff --git a/src/malloc.c b/src/malloc.c
index 7fa50a85595b..967e000f51ba 100644
--- a/src/malloc.c
+++ b/src/malloc.c
@@ -423,7 +423,7 @@ malloc_preinit(void)
// Populate temp high ram
u32 highram_start = 0;
-u32 highram_size = BUILD_MAX_HIGHTABLE;
+u32 highram_size = BUILD_MIN_HIGHTABLE;
int i;
for (i=e820_count-1; i>=0; i--) {
struct e820entry *en = _list[i];
@@ -434,6 +434,8 @@ malloc_preinit(void)
continue;
u32 s = en->start, e = end;
if (!highram_start) {
+if (e - s > BUILD_MAX_HIGHTABLE * 16)
+highram_size = BUILD_MAX_HIGHTABLE;
u32 newe = ALIGN_DOWN(e - highram_size, MALLOC_MIN_ALIGN);
if (newe <= e && newe >= s) {
highram_start = newe;
--
2.35.1
___
SeaBIOS mailing list -- seabios@seabios.org
To unsubscribe send an email to seabios-le...@seabios.org
[SeaBIOS] [PATCH v3 0/2] use large ZoneHigh when there is enough memory
v3: - check size instead of end address. Gerd Hoffmann (2): malloc: use variable for ZoneHigh size malloc: use large ZoneHigh when there is enough memory src/config.h | 3 ++- src/malloc.c | 18 +++--- 2 files changed, 13 insertions(+), 8 deletions(-) -- 2.35.1 ___ SeaBIOS mailing list -- seabios@seabios.org To unsubscribe send an email to seabios-le...@seabios.org
[SeaBIOS] Re: [PATCH v2 2/2] malloc: use large ZoneHigh when there is enough memory
> > u32 s = en->start, e = end;
> > if (!highram_start) {
> > +if (e > BUILD_MAX_HIGHTABLE * 16)
> > +highram_size = BUILD_MAX_HIGHTABLE;
> > u32 newe = ALIGN_DOWN(e - highram_size, MALLOC_MIN_ALIGN);
> > if (newe <= e && newe >= s) {
> > highram_start = newe;
>
> Thanks. At a high-level, it looks fine. However, I think the above
> might introduce a corner case where a fragmented e820 might fail to
> find any ZoneHigh.
Looking at the size instead of the end address should fix that, i.e.
if (e - s > BUILD_MAX_HIGHTABLE * 16)
(no difference for qemu because there is a single e820 ram region
with start=0 below 4G)
take care,
Gerd
___
SeaBIOS mailing list -- seabios@seabios.org
To unsubscribe send an email to seabios-le...@seabios.org
[SeaBIOS] [PATCH v2 0/2] use large ZoneHigh when there is enough memory
Gerd Hoffmann (2): malloc: use variable for ZoneHigh size malloc: use large ZoneHigh when there is enough memory src/config.h | 3 ++- src/malloc.c | 18 +++--- 2 files changed, 13 insertions(+), 8 deletions(-) -- 2.35.1 ___ SeaBIOS mailing list -- seabios@seabios.org To unsubscribe send an email to seabios-le...@seabios.org
[SeaBIOS] [PATCH v2 2/2] malloc: use large ZoneHigh when there is enough memory
In case there is enough memory installed use a large ZoneHigh.
Signed-off-by: Gerd Hoffmann
---
src/config.h | 3 ++-
src/malloc.c | 4 +++-
2 files changed, 5 insertions(+), 2 deletions(-)
diff --git a/src/config.h b/src/config.h
index 93c8dbc2d530..9abe355b6c47 100644
--- a/src/config.h
+++ b/src/config.h
@@ -17,7 +17,8 @@
// Maximum number of map entries in the e820 map
#define BUILD_MAX_E820 32
// Space to reserve in high-memory for tables
-#define BUILD_MAX_HIGHTABLE (256*1024)
+#define BUILD_MIN_HIGHTABLE (256*1024)
+#define BUILD_MAX_HIGHTABLE (16*1024*1024)
// Largest supported externaly facing drive id
#define BUILD_MAX_EXTDRIVE 16
// Number of bytes the smbios may be and still live in the f-segment
diff --git a/src/malloc.c b/src/malloc.c
index 7fa50a85595b..553164d53a38 100644
--- a/src/malloc.c
+++ b/src/malloc.c
@@ -423,7 +423,7 @@ malloc_preinit(void)
// Populate temp high ram
u32 highram_start = 0;
-u32 highram_size = BUILD_MAX_HIGHTABLE;
+u32 highram_size = BUILD_MIN_HIGHTABLE;
int i;
for (i=e820_count-1; i>=0; i--) {
struct e820entry *en = _list[i];
@@ -434,6 +434,8 @@ malloc_preinit(void)
continue;
u32 s = en->start, e = end;
if (!highram_start) {
+if (e > BUILD_MAX_HIGHTABLE * 16)
+highram_size = BUILD_MAX_HIGHTABLE;
u32 newe = ALIGN_DOWN(e - highram_size, MALLOC_MIN_ALIGN);
if (newe <= e && newe >= s) {
highram_start = newe;
--
2.35.1
___
SeaBIOS mailing list -- seabios@seabios.org
To unsubscribe send an email to seabios-le...@seabios.org
[SeaBIOS] [PATCH v2 1/2] malloc: use variable for ZoneHigh size
Use the variable highram_size instead of the BUILD_MAX_HIGHTABLE #define
for the ZoneHigh size. Initialize the new variable with the old #define,
so behavior does not change.
This allows to easily adjust the ZoneHigh size at runtime in a followup
patch.
Signed-off-by: Gerd Hoffmann
---
src/malloc.c | 16 +---
1 file changed, 9 insertions(+), 7 deletions(-)
diff --git a/src/malloc.c b/src/malloc.c
index 3733855caf2c..7fa50a85595b 100644
--- a/src/malloc.c
+++ b/src/malloc.c
@@ -422,7 +422,8 @@ malloc_preinit(void)
e820_add(BUILD_BIOS_ADDR, BUILD_BIOS_SIZE, E820_RESERVED);
// Populate temp high ram
-u32 highram = 0;
+u32 highram_start = 0;
+u32 highram_size = BUILD_MAX_HIGHTABLE;
int i;
for (i=e820_count-1; i>=0; i--) {
struct e820entry *en = _list[i];
@@ -432,10 +433,10 @@ malloc_preinit(void)
if (en->type != E820_RAM || end > 0x)
continue;
u32 s = en->start, e = end;
-if (!highram) {
-u32 newe = ALIGN_DOWN(e - BUILD_MAX_HIGHTABLE, MALLOC_MIN_ALIGN);
+if (!highram_start) {
+u32 newe = ALIGN_DOWN(e - highram_size, MALLOC_MIN_ALIGN);
if (newe <= e && newe >= s) {
-highram = newe;
+highram_start = newe;
e = newe;
}
}
@@ -444,9 +445,10 @@ malloc_preinit(void)
// Populate regions
alloc_add(, BUILD_STACK_ADDR, BUILD_EBDA_MINIMUM);
-if (highram) {
-alloc_add(, highram, highram + BUILD_MAX_HIGHTABLE);
-e820_add(highram, BUILD_MAX_HIGHTABLE, E820_RESERVED);
+if (highram_start) {
+dprintf(3, "malloc: using %dk for ZoneHigh\n", highram_size / 1024);
+alloc_add(, highram_start, highram_start + highram_size);
+e820_add(highram_start, highram_size, E820_RESERVED);
}
}
--
2.35.1
___
SeaBIOS mailing list -- seabios@seabios.org
To unsubscribe send an email to seabios-le...@seabios.org
[SeaBIOS] [PATCH] memory: reserve more space for ZoneHigh
Bump BUILD_MAX_HIGHTABLE from 256k to 1M to avoid running out of memory with very large smbios tables. Signed-off-by: Gerd Hoffmann --- src/config.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/config.h b/src/config.h index 93c8dbc2d530..f4b19898a1f0 100644 --- a/src/config.h +++ b/src/config.h @@ -17,7 +17,7 @@ // Maximum number of map entries in the e820 map #define BUILD_MAX_E820 32 // Space to reserve in high-memory for tables -#define BUILD_MAX_HIGHTABLE (256*1024) +#define BUILD_MAX_HIGHTABLE (1024*1024) // Largest supported externaly facing drive id #define BUILD_MAX_EXTDRIVE 16 // Number of bytes the smbios may be and still live in the f-segment -- 2.35.1 ___ SeaBIOS mailing list -- seabios@seabios.org To unsubscribe send an email to seabios-le...@seabios.org
[SeaBIOS] Re: [PATCH 0/2] improve ZoneHigh memory management
Hi, > Unused space gets returned to the e820 map before boot, so there is > generally not much harm in increasing it. Ah, missed that detail ... So simply bumping it to 1M or so is fine and does not waste memory? > What's using the ZoneHigh region that is so large that we need to > expand it? zonehigh is 256k. Largest allocation usually are the acpi tables (128k for a typical q35 config) and that is the one which typically fails when the other allocations sum up to > 128k so there is less than 128k free space left. Lots of vcpus (~800 IIRC) leading to large smbios tables are one way to trigger this. I've also seen allocation failures with many disk devices, although I'm not sure whenever that was zonehigh or zonelow. And the change to only initialize bootable disks should help with that one too. take care, Gerd ___ SeaBIOS mailing list -- seabios@seabios.org To unsubscribe send an email to seabios-le...@seabios.org
[SeaBIOS] [PATCH] qemu: disable builtin acpi and smbios tables by default.
qemu provides acpi and smbios tables via fw_cfg for many years now. The builtin tables shipped by seabios are only used as fallback for old qemu versions. qemu is about to drop backward compatibility for old versions, machine types for versions 1.4 to 1.7 are deprecated, which turns the fallbacks into dead code. This patch flips the default for the config options controlling the fallback smbios and acpi tables from 'Yes' to 'No'. Eventually the code will be removed altogether at some point in the future. Signed-off-by: Gerd Hoffmann --- src/Kconfig | 8 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/src/Kconfig b/src/Kconfig index 3a8ffa15fded..83ddf45143c3 100644 --- a/src/Kconfig +++ b/src/Kconfig @@ -494,25 +494,25 @@ menu "BIOS Tables" Support generation of MPTable. config SMBIOS bool "SMBIOS" -default y +default n help Support generation of SM BIOS tables. This is also sometimes called DMI. config ACPI bool "ACPI" -default y +default n help Support generation of ACPI tables. config ACPI_DSDT bool "Include default ACPI DSDT" -default y +default n depends on ACPI help Include default DSDT ACPI table in BIOS. Required for QEMU 1.3 and older. This option can be disabled for QEMU 1.4 and newer to save some space in the ROM file. -If unsure, say Y. +If unsure, say N. config FW_ROMFILE_LOAD bool "Load BIOS tables from ROM files" depends on QEMU_HARDWARE -- 2.35.1 ___ SeaBIOS mailing list -- seabios@seabios.org To unsubscribe send an email to seabios-le...@seabios.org
[SeaBIOS] [PATCH 2/2] Revert "pmm: use tmp zone on oom"
This reverts commit a638acfa4cc772b42093c8bfe55669829a641293.
Not needed any more now that ZoneHigh is expanded on demand.
Signed-off-by: Gerd Hoffmann
---
src/pmm.c | 13 -
1 file changed, 13 deletions(-)
diff --git a/src/pmm.c b/src/pmm.c
index 28b253b2d33c..640341472486 100644
--- a/src/pmm.c
+++ b/src/pmm.c
@@ -8,7 +8,6 @@
#include "config.h" // CONFIG_*
#include "malloc.h" // _malloc
#include "output.h" // dprintf
-#include "e820map.h" // struct e820entry
#include "std/pmm.h" // PMM_SIGNATURE
#include "string.h" // checksum
#include "util.h" // pmm_init
@@ -76,18 +75,6 @@ handle_pmm00(u16 *args)
break;
case 2:
data = malloc_palloc(highzone, size, align);
-if (!data && (flags & 8)) {
-/*
- * We are out of meory. So go allocate from the (big)
- * ZoneTmpHigh instead and reserve the block in the e820
- * map so the OS will not override it. That way we can
- * handle big permanent allocations without needing a big
- * ZoneHigh.
- */
-data = malloc_palloc(, size, align);
-if (data)
-e820_add(data, size, E820_RESERVED);
-}
break;
case 3: {
data = malloc_palloc(lowzone, size, align);
--
2.35.1
___
SeaBIOS mailing list -- seabios@seabios.org
To unsubscribe send an email to seabios-le...@seabios.org
[SeaBIOS] [PATCH 1/2] malloc: add on demand ZoneHigh expansion support
When running out of memory in ZoneHigh go alloc memory from ZoneTmpHigh,
add it as reserved to the e820 map and expand ZoneHigh
Signed-off-by: Gerd Hoffmann
---
src/malloc.c | 16
1 file changed, 16 insertions(+)
diff --git a/src/malloc.c b/src/malloc.c
index 3733855caf2c..02067b5370f9 100644
--- a/src/malloc.c
+++ b/src/malloc.c
@@ -226,6 +226,20 @@ zonelow_expand(u32 size, u32 align, struct allocinfo_s
*fill)
return alloc_new(, size, align, fill);
}
+static u32
+zonehigh_expand(u32 size, u32 align, struct allocinfo_s *fill)
+{
+u32 xsize = ALIGN(size, BUILD_MAX_HIGHTABLE);
+u32 xalign = align > PAGE_SIZE ? align : PAGE_SIZE;
+u32 xdata = malloc_palloc(, xsize, xalign);
+if (!xdata)
+return 0;
+
+alloc_add(, xdata, xdata + xsize);
+e820_add(xdata, size, E820_RESERVED);
+return alloc_new(, size, align, fill);
+}
+
/
* tracked memory allocations
@@ -245,6 +259,8 @@ malloc_palloc(struct zone_s *zone, u32 size, u32 align)
u32 data = alloc_new(zone, size, align, );
if (!CONFIG_MALLOC_UPPERMEMORY && !data && zone == )
data = zonelow_expand(size, align, );
+if (!data && zone == )
+data = zonehigh_expand(size, align, );
if (!data)
return 0;
--
2.35.1
___
SeaBIOS mailing list -- seabios@seabios.org
To unsubscribe send an email to seabios-le...@seabios.org
[SeaBIOS] [PATCH 0/2] improve ZoneHigh memory management
When running out of memory get a chunk of memory from ZoneTmpHigh to expand ZoneHigh. Drop simliar logic fro pmm code because it's not needed ay more. This fixes some scalability problems, for example with lots of vcpus, where seabios runs out of memory due to large smbios/acpi tables. Gerd Hoffmann (2): malloc: add on demand ZoneHigh expansion support Revert "pmm: use tmp zone on oom" src/malloc.c | 16 src/pmm.c| 13 - 2 files changed, 16 insertions(+), 13 deletions(-) -- 2.35.1 ___ SeaBIOS mailing list -- seabios@seabios.org To unsubscribe send an email to seabios-le...@seabios.org
[SeaBIOS] Re: [PATCH] MP: fix mptable interrupt source generation for pci devices
> > diff --git a/src/fw/mptable.c b/src/fw/mptable.c > > index 47385cc..3a7b02f 100644 > > --- a/src/fw/mptable.c > > +++ b/src/fw/mptable.c > > If you look at the top of that file you'll see the notice: > > // DO NOT ADD NEW FEATURES HERE. (See paravirt.c / biostables.c instead.) > > The mptable.c file in seabios is no longer modified. If a guest OS > needs a different mptable then it will be necessary to extend qemu to > pass the desired mptable to seabios (as is done for smbios and acpi). Maybe its time to think about removing this code? Current state of affairs in qemu is: # qemu-default -M help Supported machines are: [ ... ] pc-i440fx-2.1Standard PC (i440FX + PIIX, 1996) pc-i440fx-2.0Standard PC (i440FX + PIIX, 1996) pc-i440fx-1.7Standard PC (i440FX + PIIX, 1996) (deprecated) pc-i440fx-1.6Standard PC (i440FX + PIIX, 1996) (deprecated) pc-i440fx-1.5Standard PC (i440FX + PIIX, 1996) (deprecated) pc-i440fx-1.4Standard PC (i440FX + PIIX, 1996) (deprecated) [ ... ] So qemu plans to remove support for machine types 1.7 and older, this will probably happen later this year in the 7.1 or 7.2 release. qemu added support for passing acpi tables to the firmware in version 1.7, so the compatibility code is only used for machine types 1.6 and older. So in a year or so the only purpose the compatibility code will serve is confusing people ... take care, Gerd ___ SeaBIOS mailing list -- seabios@seabios.org To unsubscribe send an email to seabios-le...@seabios.org
[SeaBIOS] Re: [PATCH 0/2] Fix reset issue with QEMU -machine q35
On Sun, Mar 20, 2022 at 10:45:00AM +0100, Volker Rümelin wrote: > This reset issue was reported on the QEMU issue tracker at > https://gitlab.com/qemu-project/qemu/-/issues/766 > > A reset with QEMU -machine q35 -accel tcg leads to a reset loop > and with -machine q35 -accel kvm the reset only works because > KVM ignores the read-only semantics of the C-F segments. > > Details about the issue are in "reset: force standard PCI > configuration access". > > Volker Rümelin (2): > pci: refactor the pci_config_*() functions > reset: force standard PCI configuration access Series looks good to me. Reviewed-by: Gerd Hoffmann take care, Gerd ___ SeaBIOS mailing list -- seabios@seabios.org To unsubscribe send an email to seabios-le...@seabios.org
[SeaBIOS] Re: Cut 1.15.1 release?
On Thu, Jan 27, 2022 at 05:43:32PM +0100, Paul Menzel wrote: > Dear SeaBIOS folks, > > > with the latest NVMe fixes, would it make sense to tag a 1.15.1 release? > > The 1.16.0 release is planned for end of February, as far as I understand > it. Maybe that could be moved up two weeks? Going straight to 1.16.0 looks more useful to me. I don't feel like rushing a 1.15.1 release with patches commited only yesterday, also there are lots of fixes so a 1.15.1 would have a rather big portion of the patches in master cherry-picked. take care, Gerd ___ SeaBIOS mailing list -- seabios@seabios.org To unsubscribe send an email to seabios-le...@seabios.org
[SeaBIOS] Re: new november release?
On Thu, Jan 13, 2022 at 11:21:18AM -0500, Kevin O'Connor wrote: > On Thu, Jan 13, 2022 at 11:56:35AM +0100, Gerd Hoffmann wrote: > > Hi, > > > > > 2. Commit the smbios 3 changes (and pcie-pci-bridge changes) and > > >release v1.15.0 in early January. > > > > I think all pending patches have been applied meanwhile. > > So time to enter 1.15 freeze and release in ~2 weeks? > > It feels we just made a release. Is there a timeline you'd like to > reach? Otherwise, how about we target end of February for next > release. Basically I want a release with the smbios3 changes. Makes it a bit simpler to do the finishing touches on the qemu side (most of the code is already there, basically it'll be switching the default from smbios2 to smbios3). I can live with an end of February target, can use a snapshot for qemu then and update again to -final before qemu 7.0 releases. On the other hand I don't see the benefits in waiting given that there are no pending changes atm (other than the warning fix posted today). take care, Gerd ___ SeaBIOS mailing list -- seabios@seabios.org To unsubscribe send an email to seabios-le...@seabios.org
[SeaBIOS] Re: new november release?
On Thu, Jan 13, 2022 at 12:06:06PM +0100, Paul Menzel wrote: > Dear Gerd, > > > Am 13.01.22 um 11:56 schrieb Gerd Hoffmann: > > > > 2. Commit the smbios 3 changes (and pcie-pci-bridge changes) and > > > release v1.15.0 in early January. > > > > I think all pending patches have been applied meanwhile. > > So time to enter 1.15 freeze and release in ~2 weeks? > > 1.15.0 was tagged/released already on December 2nd. 2021. Do you mean 1.16? Oh yea, 1.16 of course. take care, Gerd ___ SeaBIOS mailing list -- seabios@seabios.org To unsubscribe send an email to seabios-le...@seabios.org
[SeaBIOS] Re: new november release?
Hi, > 2. Commit the smbios 3 changes (and pcie-pci-bridge changes) and >release v1.15.0 in early January. I think all pending patches have been applied meanwhile. So time to enter 1.15 freeze and release in ~2 weeks? take care, Gerd ___ SeaBIOS mailing list -- seabios@seabios.org To unsubscribe send an email to seabios-le...@seabios.org
[SeaBIOS] [PATCH] svgamodes: add standard 4k modes
Add all three 4k modes. Computer monitors typically use
the first one (3840x2160).
Add 16 and 32 bpp variants. 24bpp is dead these days, and
software which is so old that still uses those modes most
likely doesn't even know what 4k is.
Signed-off-by: Gerd Hoffmann
---
vgasrc/svgamodes.c | 8
1 file changed, 8 insertions(+)
diff --git a/vgasrc/svgamodes.c b/vgasrc/svgamodes.c
index 6e494c719f39..2543b9545524 100644
--- a/vgasrc/svgamodes.c
+++ b/vgasrc/svgamodes.c
@@ -92,5 +92,13 @@ struct generic_svga_mode svga_modes[] VAR16 = {
{ 0x196, { MM_DIRECT, 2560, 1440, 16, 8, 16, SEG_GRAPH } },
{ 0x197, { MM_DIRECT, 2560, 1440, 24, 8, 16, SEG_GRAPH } },
{ 0x198, { MM_DIRECT, 2560, 1440, 32, 8, 16, SEG_GRAPH } },
+
+/* 4k modes */
+{ 0x199, { MM_DIRECT, 3840, 2160, 16, 8, 16, SEG_GRAPH } },
+{ 0x19a, { MM_DIRECT, 3840, 2160, 32, 8, 16, SEG_GRAPH } },
+{ 0x19b, { MM_DIRECT, 4096, 2160, 16, 8, 16, SEG_GRAPH } },
+{ 0x19c, { MM_DIRECT, 4096, 2160, 32, 8, 16, SEG_GRAPH } },
+{ 0x19d, { MM_DIRECT, 5120, 2160, 16, 8, 16, SEG_GRAPH } },
+{ 0x19e, { MM_DIRECT, 5120, 2160, 32, 8, 16, SEG_GRAPH } },
};
unsigned int svga_mcount VAR16 = ARRAY_SIZE(svga_modes);
--
2.33.1
___
SeaBIOS mailing list -- seabios@seabios.org
To unsubscribe send an email to seabios-le...@seabios.org
[SeaBIOS] Re: [PATCH v4 3/3] virtio-blk.: split large IO according to size_max
On Tue, Dec 07, 2021 at 09:31:08AM +0800, Andy Pei wrote: > if driver reads data larger than VIRTIO_BLK_F_SIZE_MAX, > it will cause some issue to the DMA engine. > > So when upper software wants to read data larger than > VIRTIO_BLK_F_SIZE_MAX, virtio-blk driver split one large > request into multiple smaller ones. > > Signed-off-by: Andy Pei > Signed-off-by: Ding Limin Reviewed-by: Gerd Hoffmann ___ SeaBIOS mailing list -- seabios@seabios.org To unsubscribe send an email to seabios-le...@seabios.org
[SeaBIOS] Re: [PATCH v4 2/3] virtio-blk: abstract a function named virtio_blk_op_one_segment to handle r/w request
On Tue, Dec 07, 2021 at 09:31:07AM +0800, Andy Pei wrote: > abstract virtio-blk queue operation to form a function named > virtio_blk_op_one_segment > > Signed-off-by: Andy Pei > Signed-off-by: Ding Limin Reviewed-by: Gerd Hoffmann ___ SeaBIOS mailing list -- seabios@seabios.org To unsubscribe send an email to seabios-le...@seabios.org
[SeaBIOS] Re: [PATCH v4 1/3] virtio-blk: add feature VIRTIO_BLK_F_SIZE_MAX and VIRTIO_BLK_F_SEG_MAX
On Tue, Dec 07, 2021 at 09:31:06AM +0800, Andy Pei wrote: > according to virtio spec, add feature VIRTIO_BLK_F_SIZE_MAX > and VIRTIO_BLK_F_SEG_MAX parse to virtio blk driver. > > Signed-off-by: Andy Pei > Signed-off-by: Ding Limin Reviewed-by: Gerd Hoffmann ___ SeaBIOS mailing list -- seabios@seabios.org To unsubscribe send an email to seabios-le...@seabios.org
[SeaBIOS] Re: [PATCH v3 3/3] virtio-blk.: split large IO according to size_max
On Mon, Dec 06, 2021 at 01:38:16PM +, Pei, Andy wrote:
> Reply in line
>
>
> > +} else {
> > +struct vring_list *p_sg = [1];
>
> Not needed, you can just use sg[1].addr
> Andy: I used to think sg[1]. Length, but I am not sure. Could you please
> tell me why sg[1]. Length is not needed ?
length too of course, but you can likewise use sg[1].length and there is
no need to create that p_sg pointer.
take care,
Gerd
___
SeaBIOS mailing list -- seabios@seabios.org
To unsubscribe send an email to seabios-le...@seabios.org
[SeaBIOS] Re: [PATCH v3 3/3] virtio-blk.: split large IO according to size_max
> +} else {
> +struct vring_list *p_sg = [1];
Not needed, you can just use sg[1].addr
> +void *p = op->buf_fl;
> +u16 count = op->count;
> +
> +while (count > blk_num_max) {
while (count > 0) {
u16 blk_num = min(count, blk_num_max);
> +} else {
> +break;
> +}
> +}
> +
> +if (status != VIRTIO_BLK_S_OK)
> +return DISK_RET_EBADTRACK;
Can be moved into the while loop, you don't need the break then.
> +if (count > 0) {
> +p_sg->addr = p;
> +p_sg->length = vdrive->drive.blksize * count;
> +virtio_blk_op_one_segment(vdrive, write, sg);
> +}
Not needed with the change above.
take care,
Gerd
___
SeaBIOS mailing list -- seabios@seabios.org
To unsubscribe send an email to seabios-le...@seabios.org
[SeaBIOS] Re: [PATCH v3 2/3] virtio-blk: abstract a function named virtio_blk_op_one_segment to handle r/w request
On Fri, Dec 03, 2021 at 01:22:43PM +0800, Andy Pei wrote: > abstract virtio-blk queue operation to form a function named > virtio_blk_op_one_segment > > Signed-off-by: Andy Pei > Signed-off-by: Ding Limin Reviewed-by: Gerd Hoffmann ___ SeaBIOS mailing list -- seabios@seabios.org To unsubscribe send an email to seabios-le...@seabios.org
[SeaBIOS] Re: [PATCH v3 1/3] virtio-blk: add feature VIRTIO_BLK_F_SIZE_MAX and VIRTIO_BLK_F_SEG_MAX
Hi, > +if (features & max_segment_size) > +vdrive->drive.max_segment_size = > +vp_read(>device, struct virtio_blk_config, size_max); > +else > +vdrive->drive.max_segment_size = 0; Not needed, there is a memset(0) for the complete vdrive struct. > +dprintf(3, "virtio-blk %pP size_max=%u.\n", pci, > +vdrive->drive.max_segment_size); Can you just add that to the existing dprintf instead of adding a new line to the log? thanks, Gerd ___ SeaBIOS mailing list -- seabios@seabios.org To unsubscribe send an email to seabios-le...@seabios.org
[SeaBIOS] Re: new november release?
Hi, > I'm not sure what you'd prefer to do with the SeaBIOS release though. > We have a couple of high-level options: > > 1. Release v1.15.0 this week without these changes (tag 64f37cc5). > > 2. Commit the smbios 3 changes (and pcie-pci-bridge changes) and >release v1.15.0 in early January. You mean v1.16.0 I guess? > I suppose we could commit the changes and try to make a release in > December, but that seems like it would dilute the meaning of a > "release". If we add a 2-3 week freeze after committing the patches the release would be too late for qemu 6.2 anyway. > What are your thoughts? So tagging v1.15.0 now and plan for 1.16.0 in january (with smbios + hotplug changes) looks good to me. take care, Gerd ___ SeaBIOS mailing list -- seabios@seabios.org To unsubscribe send an email to seabios-le...@seabios.org
[SeaBIOS] Re: [PATCH v2] src/hw/virtio-blk: add feature VIRTIO_BLK_F_SIZE_MAX and VIRTIO_BLK_F_SEG_MAX
On Tue, Nov 30, 2021 at 05:23:52AM +, Pei, Andy wrote: > Hi Gerd, > > Yes, you are right. > I think reading these two config register is fine during init and align with > the virtio blk spec. It is not wrong but also pointless. > In the near future, we will working on some related work on these two value. > To be specific, we will do some modification in virtio blk driver. If driver > reads data larger than VIRTIO_BLK_F_SIZE_MAX, > it will cause some issue to the DMA engine. Please submit all changes together as patch series. thanks, Gerd ___ SeaBIOS mailing list -- seabios@seabios.org To unsubscribe send an email to seabios-le...@seabios.org
[SeaBIOS] Re: [PATCH v2] pci: reserve resources for pcie-pci-bridge to fix regressed hotplug on q35 with ACPI hotplug enabled
Hi,
> Reason for this is that commit [1] didn't take into account
> pcie-pci-bridge, marking bridge as non hotpluggable instead of
> handling it as possibly SHPC capable bridge.
> Fix issue by checking if pcie-pci-bridge is SHPC capable and
> if it is mark it as hotpluggable.
Fix #1
> With this hotplug of rtl8139 succeeds, with caveat that it fails
> initialize IO bar, which is caused by [2] which makes firmware
> skip IO reservation for any PCI device which isn't correct in case
> of pcie-pci-bridge.
> Fix it by exposing hotplug type and making resource optional
> only if PCIe hotplug is in use.
Fix #2
Can we make them two separate patches please?
> +switch (port_type) {
> +case PCI_EXP_TYPE_PCI_BRIDGE:
> +/* do nothing and check later if SHPC is enabled */
> +break;
if (port_type == PCI_EXP_TYPE_PCI_BRIDGE)
goto check_shcp;
check_shpc:
> shpc_cap = pci_find_capability(bus->bus_dev->bdf, PCI_CAP_ID_SHPC, 0);
I think this would be more readable.
thanks,
Gerd
___
SeaBIOS mailing list -- seabios@seabios.org
To unsubscribe send an email to seabios-le...@seabios.org
[SeaBIOS] Re: [PATCH v2] src/hw/virtio-blk: add feature VIRTIO_BLK_F_SIZE_MAX and VIRTIO_BLK_F_SEG_MAX
On Fri, Nov 26, 2021 at 04:06:23PM +0800, Andy Pei wrote: > according to virtio spec, add feature VIRTIO_BLK_F_SIZE_MAX > and VIRTIO_BLK_F_SEG_MAX parse to virtio blk driver. Why is this needed? The code never actually uses max_segment_size and max_segments (other than logging the values) ... take care, Gerd ___ SeaBIOS mailing list -- seabios@seabios.org To unsubscribe send an email to seabios-le...@seabios.org
[SeaBIOS] Re: new november release?
Hi, > > Damn. Support for smbiod 3.0 fall completely through the cracks: > > > > https://www.mail-archive.com/seabios@seabios.org/msg12438.html > > > > The qemu-side changes have long been merged (except for flipping the > > default to 3.0), but I didn't pay attention so the seabios patches > > didn't got merged :( > > > > I'd live to have them included in the new release, I suspect that > > implies we have to extend the freeze and release in early december? > > Yeah - if we're going to make a change now, I think we should wait a > few weeks before tagging a release. > > It's been a while since I've looked at the smbios 3 patches - are > there any changes since then? Latest version is at: https://gitlab.com/ehabkost/seabios/-/commits/work/smbios-3.0/ Rebased, but no functional changes in the smbios updates. take care, Gerd ___ SeaBIOS mailing list -- seabios@seabios.org To unsubscribe send an email to seabios-le...@seabios.org
[SeaBIOS] Re: new november release?
On Thu, Oct 21, 2021 at 09:43:39PM -0400, Kevin O'Connor wrote: > On Thu, Oct 21, 2021 at 03:01:23PM +0200, Gerd Hoffmann wrote: > > Hi, > > > > It's been a while since the last release, we have some nice but > > unreleased bits in the master branch (tpm and nvme improvements > > for example), time for a new release I think. > > > > How about freeze in a week, release by roughly mid-november? > > It's fine with me. A release in late November might be a little > easier for me. Damn. Support for smbiod 3.0 fall completely through the cracks: https://www.mail-archive.com/seabios@seabios.org/msg12438.html The qemu-side changes have long been merged (except for flipping the default to 3.0), but I didn't pay attention so the seabios patches didn't got merged :( I'd live to have them included in the new release, I suspect that implies we have to extend the freeze and release in early december? take care, Gerd ___ SeaBIOS mailing list -- seabios@seabios.org To unsubscribe send an email to seabios-le...@seabios.org
[SeaBIOS] Re: new november release?
On Thu, Oct 21, 2021 at 09:43:39PM -0400, Kevin O'Connor wrote: > On Thu, Oct 21, 2021 at 03:01:23PM +0200, Gerd Hoffmann wrote: > > Hi, > > > > It's been a while since the last release, we have some nice but > > unreleased bits in the master branch (tpm and nvme improvements > > for example), time for a new release I think. > > > > How about freeze in a week, release by roughly mid-november? > > It's fine with me. A release in late November might be a little > easier for me. As long as is actually happens in November not December it should be fine with the qemu release schedule. take care, Gerd ___ SeaBIOS mailing list -- seabios@seabios.org To unsubscribe send an email to seabios-le...@seabios.org
[SeaBIOS] new november release?
Hi, It's been a while since the last release, we have some nice but unreleased bits in the master branch (tpm and nvme improvements for example), time for a new release I think. How about freeze in a week, release by roughly mid-november? take care, Gerd ___ SeaBIOS mailing list -- seabios@seabios.org To unsubscribe send an email to seabios-le...@seabios.org
[SeaBIOS] Re: [PATCH v2] virtio-scsi: initialize the ctrl and event vq
Hi, > > IMHO this must be fixed in vhost-user-scsi no matter what. Host > > processes crashing in case the guest doesn't behave as expected > > is a security problem. > Yes, the backend should be fixed. > However, we may as well initialize these two vqs, because other virtio > frontend drivers have implemented these > as I know. It's good for compatibility. Is this required by the virtio spec? I don't think so. > This crash is that some vring(controlq, eventq) aren't initialized > done from vhost-user aspect. > And spdk/dpdk handles incoming events from theses queues, but the > vhost-user device isn't RUNNING > status, becase some vqs are not ready, so the destruction is bad. The device should look at the status bits. https://docs.oasis-open.org/virtio/virtio/v1.1/csprd01/virtio-v1.1-csprd01.html#x1-930001 When the driver sets DRIVER_OK it is done setting up virtqueues. When some of them are not ready the driver apparently doesn't want use them. > BTW, do you accept a future patch that implements the virtio SCSI hotplug? Well, the problem with hotplug is that the BIOS interfaces have been created in the 1980-ies and are not designed with hotplug in mind. So retrofitting hotplug support into that is a rather hard problem and the benefits are questionable given that the BIOS typically runs only for a very short time, before the real operating system takes over control. take care, Gerd ___ SeaBIOS mailing list -- seabios@seabios.org To unsubscribe send an email to seabios-le...@seabios.org
[SeaBIOS] Re: [PATCH v2] virtio-scsi: initialize the ctrl and event vq
On Tue, Aug 31, 2021 at 08:23:39PM +0800, Li Feng wrote:
> Currently, virtio-scsi doesn't support any control or event message, this
> patch
> adds the basic initialization.
>
> Some backends need this feature, like dpdk/spdk vhost-user backend.
>
> Reproduce:
> 1. Start spdk vhost-user-scsi backend;
> 2. Create a vm with a SCSI vhost-user-scsi disk and start the vm;
> 3. Mount an iso to the vm without an OS;
> 3. Stop the vhost-user-scsi backend;
> 5. Vhost-user-scsi backend will crash before exiting when cleaning the
> resources.
IMHO this must be fixed in vhost-user-scsi no matter what. Host
processes crashing in case the guest doesn't behave as expected
is a security problem.
> The reason is that the seabios virtio-scsi only initializes the req vq,
> then the spdk/dpdk treats it a not good session, it's hard to handle this
> tricky
> issue from dpdk architecture.
What is the exact problem here? vhost-user-scsi trying to send a
hotplug event (when adding the iso, probably as virtual cdrom) and
seabios not listening?
> +if (vp_find_vq(vp, 1, ) < 0 ) {
> +dprintf(1, "fail to find event vq for virtio-scsi %pP\n", pci);
> +goto fail;
> +}
That alone doesn't allow receiving events (no recv buffers added). Also
note that seabios does not support hotplugging devices, so the only
thing we could do with those events is to throw them away.
take care,
Gerd
___
SeaBIOS mailing list -- seabios@seabios.org
To unsubscribe send an email to seabios-le...@seabios.org
[SeaBIOS] Re: [PATCH v2] nvme: don't keep probing namespaces after an active one has been found
Hi,
> -static void
> +int
> nvme_probe_ns(struct nvme_ctrl *ctrl, u32 ns_idx, u8 mdts)
Why drop the static?
> -/* Populate namespace IDs */
> +/* Find first active namespace. */
> int ns_idx;
> -for (ns_idx = 0; ns_idx < ctrl->ns_count; ns_idx++) {
> -nvme_probe_ns(ctrl, ns_idx, identify->mdts);
> +rc = -1;
> +for (ns_idx = 0; ns_idx < ctrl->ns_count && rc; ns_idx++) {
> +rc = nvme_probe_ns(ctrl, ns_idx, identify->mdts);
> +}
I think we should make this depend on skip_nonbootable,
i.e. have something along the lines of ...
if (skip_nonbootable) {
if (rc == 0) {
break;
}
}
... inside the loop. When we have bootorder support for
namespaces we can refine the logic inside the
"if (skip_nonbootable)" block.
take care,
Gerd
___
SeaBIOS mailing list -- seabios@seabios.org
To unsubscribe send an email to seabios-le...@seabios.org
[SeaBIOS] Re: [PATCH] nvme: don't keep probing namespaces after an active one has been found
> > [ just back from vacation ] > > > > Well, assuming the first namespace is the one you want actually boot > > from. Which I expect is the common case, but who knows how people > > use their machines ... > > > > IIRC there is some work in progress to add bootorder support for > > namespaces, where do we stand with that? > > IIUC I got the go-ahead to implement this in QEMU, so let's see how that > goes. Then we can look at the SeaBIOS patch I suppose. > > > Once we have this we should be > > able to extend the skip_nonbootable logic to handle not only controllers > > but also namespaces. With that we should be able to initialize the > > correct boot namespaces instead of picking the first namespace. > > I would expect that selecting a particular namespace (which will be enabled > by the QEMU patch) will be optional. Therefore, we might still have to figure > out from which namespace to boot from, so we'll be in the same situation as > we are now (an NVMe controller with lots of namespaces). So, I think the > patch I propose is still useful? Yes, when bootorder doesn't specify one (or more) specific namespace(s) picking the first is fine. The patch seems to do some unneeded / unrelated changes though. Why do you move the boot_add() call? Why the desc changes? Why return the namespace? Just returning a int or bool telling whenever the namespace is active or not should be enough, no? take care, Gerd ___ SeaBIOS mailing list -- seabios@seabios.org To unsubscribe send an email to seabios-le...@seabios.org
[SeaBIOS] Re: [PATCH] nvme: don't keep probing namespaces after an active one has been found
On Thu, Jul 01, 2021 at 02:20:47PM +, Thanos Makatos wrote: > From: Thanos Makatos > > The current implementation keeps probing NVMe namespaces even if an > active one has been found. This is unnecessary and most importantly > results in memory allocation failure if the are more than a few dozens > of nmespaces. Also, not probing the remaining namespaces after having > found an active one reduces boot time. [ just back from vacation ] Well, assuming the first namespace is the one you want actually boot from. Which I expect is the common case, but who knows how people use their machines ... IIRC there is some work in progress to add bootorder support for namespaces, where do we stand with that? Once we have this we should be able to extend the skip_nonbootable logic to handle not only controllers but also namespaces. With that we should be able to initialize the correct boot namespaces instead of picking the first namespace. take care, Gerd ___ SeaBIOS mailing list -- seabios@seabios.org To unsubscribe send an email to seabios-le...@seabios.org
[SeaBIOS] Re: [PATCH v3 1/2] svgamodes: Add all HD and QXGA resolutions
On Tue, Jul 13, 2021 at 05:32:27AM -0400, Elliot Killick via SeaBIOS wrote:
> Add support for all high-definition and quad extended graphics array
> resolutions as listed on Wikipedia.
>
> https://en.wikipedia.org/wiki/Graphics_display_resolution
>
> Signed-off-by: Elliot Killick
> ---
> vgasrc/svgamodes.c | 87 +++---
> 1 file changed, 75 insertions(+), 12 deletions(-)
>
> diff --git a/vgasrc/svgamodes.c b/vgasrc/svgamodes.c
> index 6e494c7..af71853 100644
> --- a/vgasrc/svgamodes.c
> +++ b/vgasrc/svgamodes.c
> @@ -72,25 +72,88 @@ struct generic_svga_mode svga_modes[] VAR16 = {
> { 0x184, { MM_DIRECT, 1680, 1050, 16, 8, 16, SEG_GRAPH } },
> { 0x185, { MM_DIRECT, 1680, 1050, 24, 8, 16, SEG_GRAPH } },
> { 0x186, { MM_DIRECT, 1680, 1050, 32, 8, 16, SEG_GRAPH } },
> -{ 0x187, { MM_DIRECT, 1920, 1200, 16, 8, 16, SEG_GRAPH } },
> -{ 0x188, { MM_DIRECT, 1920, 1200, 24, 8, 16, SEG_GRAPH } },
> { 0x189, { MM_DIRECT, 1920, 1200, 32, 8, 16, SEG_GRAPH } },
> -{ 0x18a, { MM_DIRECT, 2560, 1600, 16, 8, 16, SEG_GRAPH } },
> -{ 0x18b, { MM_DIRECT, 2560, 1600, 24, 8, 16, SEG_GRAPH } },
> -{ 0x18c, { MM_DIRECT, 2560, 1600, 32, 8, 16, SEG_GRAPH } },
Huh? Intentionally deleted?
take care,
Gerd
___
SeaBIOS mailing list -- seabios@seabios.org
To unsubscribe send an email to seabios-le...@seabios.org
[SeaBIOS] Re: [PATCH v3] Increate BUILD_MIN_BIOSTABLE for large roms
On Wed, Jun 02, 2021 at 11:31:46AM -0400, Kevin O'Connor wrote: > On Mon, May 31, 2021 at 07:55:28AM +0200, Gerd Hoffmann wrote: > > BUILD_MIN_BIOSTABLE reserves space in the f-segment. Some data > > structures -- for example disk drives known to seabios -- must be > > stored there, so the space available here limits the number of > > devices seabios is able to manage. > > > > This patch sets BUILD_MIN_BIOSTABLE to 8k for bios images being 256k or > > larger in size. 32bit code is moved off in that case, so we have more > > room in the f-segment then. > > Thanks. Looks good to me. Pushed. take care, Gerd ___ SeaBIOS mailing list -- seabios@seabios.org To unsubscribe send an email to seabios-le...@seabios.org
[SeaBIOS] Re: [PATCH v3] Increate BUILD_MIN_BIOSTABLE for large roms
On Mon, May 31, 2021 at 08:02:52AM +0200, Paul Menzel wrote:
> Dear Gerd,
>
>
> Am 31.05.21 um 07:55 schrieb Gerd Hoffmann:
>
> Small nit for the commit message summary: Increa*s*e.
>
> > BUILD_MIN_BIOSTABLE reserves space in the f-segment. Some data
> > structures -- for example disk drives known to seabios -- must be
> > stored there, so the space available here limits the number of
> > devices seabios is able to manage.
>
> Do you have an example command how to reproduce this with QEMU?
Just create a guest with lots of disks. Easiest is using
virtio-scsi-pci because you can plug tons of disks ("-device scsi-hd")
into a single host adapter then.
take care,
Gerd
___
SeaBIOS mailing list -- seabios@seabios.org
To unsubscribe send an email to seabios-le...@seabios.org
[SeaBIOS] [PATCH v3] Increate BUILD_MIN_BIOSTABLE for large roms
BUILD_MIN_BIOSTABLE reserves space in the f-segment. Some data
structures -- for example disk drives known to seabios -- must be
stored there, so the space available here limits the number of
devices seabios is able to manage.
This patch sets BUILD_MIN_BIOSTABLE to 8k for bios images being 256k or
larger in size. 32bit code is moved off in that case, so we have more
room in the f-segment then.
Signed-off-by: Gerd Hoffmann
---
scripts/layoutrom.py | 4
1 file changed, 4 insertions(+)
diff --git a/scripts/layoutrom.py b/scripts/layoutrom.py
index 6616721d1b58..abebf0211fa9 100755
--- a/scripts/layoutrom.py
+++ b/scripts/layoutrom.py
@@ -651,6 +651,10 @@ def main():
# Read kconfig config file
config = scanconfig(cfgfile)
+# larger roms have more room in the f-segment due to moving out 32bit code
+if config.get('CONFIG_ROM_SIZE') >= 256:
+BUILD_MIN_BIOSTABLE = 8192
+
# Figure out which sections to keep.
allsections = info16[0] + info32seg[0] + info32flat[0]
symbols = {'16': info16[1], '32seg': info32seg[1], '32flat': info32flat[1]}
--
2.31.1
___
SeaBIOS mailing list -- seabios@seabios.org
To unsubscribe send an email to seabios-le...@seabios.org
[SeaBIOS] [PATCH v2] make BUILD_MIN_BIOSTABLE configurable
BUILD_MIN_BIOSTABLE reserves space in the f-segment. Some data structures -- for example disk drives known to seabios -- must be stored there, so the space available here limits the number of devices seabios is able to manage. This patch adds an config option for BUILD_MIN_BIOSTABLE so the size of the reservation can be configured at build time. Default is 8k for bios images being 256k or larger in size (32bit code is moved off then so we have more room in the f-segment), 2k (current value) otherwise. Signed-off-by: Gerd Hoffmann --- Makefile | 2 +- scripts/layoutrom.py | 3 ++- src/Kconfig | 7 +++ 3 files changed, 10 insertions(+), 2 deletions(-) diff --git a/Makefile b/Makefile index 3d8943ef5f25..ddcd1dff399d 100644 --- a/Makefile +++ b/Makefile @@ -172,7 +172,7 @@ $(OUT)romlayout16.lds: $(OUT)ccode32flat.o $(OUT)code32seg.o $(OUT)ccode16.o $(O $(Q)$(OBJDUMP) -thr $(OUT)code32flat.o > $(OUT)code32flat.o.objdump $(Q)$(OBJDUMP) -thr $(OUT)code32seg.o > $(OUT)code32seg.o.objdump $(Q)$(OBJDUMP) -thr $(OUT)code16.o > $(OUT)code16.o.objdump - $(Q)$(PYTHON) ./scripts/layoutrom.py $(OUT)code16.o.objdump $(OUT)code32seg.o.objdump $(OUT)code32flat.o.objdump $(OUT)$(KCONFIG_AUTOHEADER) $(OUT)romlayout16.lds $(OUT)romlayout32seg.lds $(OUT)romlayout32flat.lds + $(Q)$(PYTHON) ./scripts/layoutrom.py $(OUT)code16.o.objdump $(OUT)code32seg.o.objdump $(OUT)code32flat.o.objdump $(OUT)$(KCONFIG_AUTOHEADER) $(OUT)romlayout16.lds $(OUT)romlayout32seg.lds $(OUT)romlayout32flat.lds $(CONFIG_MIN_BIOSTABLE) # These are actually built by scripts/layoutrom.py above, but by pulling them # into an extra rule we prevent make -j from spawning layoutrom.py 4 times. diff --git a/scripts/layoutrom.py b/scripts/layoutrom.py index 6616721d1b58..94deca9fcc85 100755 --- a/scripts/layoutrom.py +++ b/scripts/layoutrom.py @@ -636,7 +636,8 @@ def scanconfig(file): def main(): # Get output name -in16, in32seg, in32flat, cfgfile, out16, out32seg, out32flat = sys.argv[1:] +in16, in32seg, in32flat, cfgfile, out16, out32seg, out32flat, biostable = sys.argv[1:] +BUILD_MIN_BIOSTABLE = biostable * 1024 # Read in the objdump information infile16 = open(in16, 'r') diff --git a/src/Kconfig b/src/Kconfig index 3a8ffa15fded..95519fc50fa3 100644 --- a/src/Kconfig +++ b/src/Kconfig @@ -140,6 +140,13 @@ endchoice it into 128 KB (which was big enouth for a long time) you'll probably have to disable some featues such as xhci support. +config MIN_BIOSTABLE +int "biostable size (in KB)" +default 8 if ROM_SIZE >= 256 +default 2 +help +Memory space for BIOS tables in f-segment. + endmenu menu "Hardware support" -- 2.31.1 ___ SeaBIOS mailing list -- seabios@seabios.org To unsubscribe send an email to seabios-le...@seabios.org
[SeaBIOS] [PATCH 1/2] nvme: improve namespace allocation
Instead of allocating a big array upfront go probe the namespaces and
only allocate an nvme_namespace struct for those namespaces which are
actually active.
Signed-off-by: Gerd Hoffmann
---
src/hw/nvme-int.h | 1 -
src/hw/nvme.c | 40
2 files changed, 16 insertions(+), 25 deletions(-)
diff --git a/src/hw/nvme-int.h b/src/hw/nvme-int.h
index 7947b29c9660..a4c1555cc058 100644
--- a/src/hw/nvme-int.h
+++ b/src/hw/nvme-int.h
@@ -103,7 +103,6 @@ struct nvme_ctrl {
struct nvme_cq admin_cq;
u32 ns_count;
-struct nvme_namespace *ns;
struct nvme_sq io_sq;
struct nvme_cq io_cq;
diff --git a/src/hw/nvme.c b/src/hw/nvme.c
index f26b811e88bd..f64eba880a83 100644
--- a/src/hw/nvme.c
+++ b/src/hw/nvme.c
@@ -234,11 +234,9 @@ nvme_admin_identify_ns(struct nvme_ctrl *ctrl, u32 ns_id)
}
static void
-nvme_probe_ns(struct nvme_ctrl *ctrl, struct nvme_namespace *ns, u32 ns_id,
- u8 mdts)
+nvme_probe_ns(struct nvme_ctrl *ctrl, u32 ns_idx, u8 mdts)
{
-ns->ctrl = ctrl;
-ns->ns_id = ns_id;
+u32 ns_id = ns_idx + 1;
struct nvme_identify_ns *id = nvme_admin_identify_ns(ctrl, ns_id);
if (!id) {
@@ -254,12 +252,21 @@ nvme_probe_ns(struct nvme_ctrl *ctrl, struct
nvme_namespace *ns, u32 ns_id,
goto free_buffer;
}
-ns->lba_count = id->nsze;
-if (!ns->lba_count) {
+if (!id->nsze) {
dprintf(2, "NVMe NS %u is inactive.\n", ns_id);
goto free_buffer;
}
+struct nvme_namespace *ns = malloc_fseg(sizeof(*ns));
+if (!ns) {
+warn_noalloc();
+goto free_buffer;
+}
+memset(ns, 0, sizeof(*ns));
+ns->ctrl = ctrl;
+ns->ns_id = ns_id;
+ns->lba_count = id->nsze;
+
struct nvme_lba_format *fmt = >lbaf[current_lba_format];
ns->block_size= 1U << fmt->lbads;
@@ -269,10 +276,11 @@ nvme_probe_ns(struct nvme_ctrl *ctrl, struct
nvme_namespace *ns, u32 ns_id,
/* If we see devices that trigger this path, we need to increase our
buffer size. */
warn_internalerror();
+free(ns);
goto free_buffer;
}
-ns->drive.cntl_id = ns - ctrl->ns;
+ns->drive.cntl_id = ns_idx;
ns->drive.removable = 0;
ns->drive.type = DTYPE_NVME;
ns->drive.blksize = ns->block_size;
@@ -527,13 +535,6 @@ nvme_create_io_queues(struct nvme_ctrl *ctrl)
return -1;
}
-static void
-nvme_destroy_io_queues(struct nvme_ctrl *ctrl)
-{
-nvme_destroy_sq(>io_sq);
-nvme_destroy_cq(>io_cq);
-}
-
/* Waits for CSTS.RDY to match rdy. Returns 0 on success. */
static int
nvme_wait_csts_rdy(struct nvme_ctrl *ctrl, unsigned rdy)
@@ -627,24 +628,15 @@ nvme_controller_enable(struct nvme_ctrl *ctrl)
goto err_destroy_admin_sq;
}
-ctrl->ns = malloc_fseg(sizeof(*ctrl->ns) * ctrl->ns_count);
-if (!ctrl->ns) {
-warn_noalloc();
-goto err_destroy_ioq;
-}
-memset(ctrl->ns, 0, sizeof(*ctrl->ns) * ctrl->ns_count);
-
/* Populate namespace IDs */
int ns_idx;
for (ns_idx = 0; ns_idx < ctrl->ns_count; ns_idx++) {
-nvme_probe_ns(ctrl, >ns[ns_idx], ns_idx + 1, identify->mdts);
+nvme_probe_ns(ctrl, ns_idx, identify->mdts);
}
dprintf(3, "NVMe initialization complete!\n");
return 0;
- err_destroy_ioq:
-nvme_destroy_io_queues(ctrl);
err_destroy_admin_sq:
nvme_destroy_sq(>admin_sq);
err_destroy_admin_cq:
--
2.31.1
___
SeaBIOS mailing list -- seabios@seabios.org
To unsubscribe send an email to seabios-le...@seabios.org
[SeaBIOS] [PATCH 2/2] nvme: drive desc should not include the newline
Signed-off-by: Gerd Hoffmann --- 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 f64eba880a83..746e4682d318 100644 --- a/src/hw/nvme.c +++ b/src/hw/nvme.c @@ -297,11 +297,11 @@ nvme_probe_ns(struct nvme_ctrl *ctrl, u32 ns_idx, u8 mdts) ns->dma_buffer = zalloc_page_aligned(, NVME_PAGE_SIZE); char *desc = znprintf(MAXDESCSIZE, "NVMe NS %u: %llu MiB (%llu %u-byte " - "blocks + %u-byte metadata)\n", + "blocks + %u-byte metadata)", ns_id, (ns->lba_count * ns->block_size) >> 20, ns->lba_count, ns->block_size, ns->metadata_size); -dprintf(3, "%s", desc); +dprintf(3, "%s\n", desc); boot_add_hd(>drive, desc, bootprio_find_pci_device(ctrl->pci)); free_buffer: -- 2.31.1 ___ SeaBIOS mailing list -- seabios@seabios.org To unsubscribe send an email to seabios-le...@seabios.org
[SeaBIOS] [PATCH 0/2] nvme fixes
Gerd Hoffmann (2): nvme: improve namespace allocation nvme: drive desc should not include the newline src/hw/nvme-int.h | 1 - src/hw/nvme.c | 44 ++-- 2 files changed, 18 insertions(+), 27 deletions(-) -- 2.31.1 ___ SeaBIOS mailing list -- seabios@seabios.org To unsubscribe send an email to seabios-le...@seabios.org
[SeaBIOS] Re: SeaBIOS fails to boot from NVMe controller with lots of namespaces
Hi, > >> No, tested with qemu.git. Plus the code the patch touches in > >> nvme_controller_enable comes after where the alloc failure happens. > > > > I haven't upstreamed the relevant QEMU patch yet as I'm waiting for the > > SeaBIOS part to be reviewed first. > > > > The alloc failure can be avoided be setting BUILD_MIN_BIOSTABLE to 32K. > > > > Okay I just tried that, on top of master. It's still not enough for > qemu's 256 namespace default, same reported error. If I override it with > `identify->nn = 128;` in nvme_controller_enable then things start working. Oh well. nvme goes allocate 256 nvme_namespace structs, even if 255 of them are not active. We can certainly do better than that, patch will follow shortly ... take care, Gerd ___ SeaBIOS mailing list -- seabios@seabios.org To unsubscribe send an email to seabios-le...@seabios.org
[SeaBIOS] Re: SeaBIOS fails to boot from NVMe controller with lots of namespaces
Hi, > > No, tested with qemu.git. Plus the code the patch touches in > > nvme_controller_enable comes after where the alloc failure happens. > > I haven't upstreamed the relevant QEMU patch yet as I'm waiting for > the SeaBIOS part to be reviewed first. Just send it to qemu-devel. The usual process is that seabios adapts to qemu changes not the other way around. take care, Gerd ___ SeaBIOS mailing list -- seabios@seabios.org To unsubscribe send an email to seabios-le...@seabios.org
[SeaBIOS] Re: SeaBIOS fails to boot from NVMe controller with lots of namespaces
Hi, > Where can I file this so it doesn't get lost? > Anyone know a qemu command line workaround? Does https://mail.coreboot.org/hyperkitty/list/seabios@seabios.org/thread/2Q7NPH7TJNHK6JGPHQL7755HILO23ISN/ help? take care, Gerd ___ SeaBIOS mailing list -- seabios@seabios.org To unsubscribe send an email to seabios-le...@seabios.org
[SeaBIOS] Re: [PATCH] fw/coreboot.c: Use coreboot table to find cbfs
Hi, > > As far I know there is no policy on that written down somewhere. In > > general we try avoid breaking backward compatibility (and thus requiring > > lockstep updates). But maintaining backward compatibility has a cost > > too, so this isn't set in stone. > > Sure, but backwards compatibility is highly valuable, so will offset > quite some cost. See Windows or the Linux kernel ABI. Well, depends ... The linux kernel's userspace ABI maintains backward compatibility, yes. And there is countless software in the world depending on that. Still there are exceptions (see cgroups move from v1 to v2). Note that the linux kernel's in-kernel interfaces are explicitly *not* backward compatible though. > Here we are talking about a firmware compatibility, arguably even > more valuable than a kernel ABI, because firmware often, and > ironically this is probably no less true for coreboot than IBV > products, simply can not be updated. > > I expect payloads to value backwards compatibility quite high. I fail to see the problem. seabios is part of the firmware, users are not going to freely mix and match versions. So if you are stuck with an old coreboot version for whatever reason, just continue using an old seabios version. It's not like seabios does see heavy development, and the changes going in are mostly for new hardware support (recent example is nvme) which doesn't buy you much on old machines. > > > > Keeping backward compatibility with the "cbfs master header" would > > > > complicate the code. > > > > > > Obviously, but is undeniably valuable, even if not to you. > > > > Well, maintaining compatibility with a version released more than five > > years ago isn't that valuable IMHO, but comes with the cost of adding > > compatibility code which most likely will never ever be actually used. > > I know that five years is forever in QEMU, Well, we are at eight years right now, maintaining backward compatibility to qemu 1.4, released in Feb 2013. Compatibility code for older versions has been dropped (last year I think). Which reminds me that we can drop CONFIG_ACPI_DSDT + dependencies from seabios. > and perhaps in particular at Red Hat. ? > Firmware is not QEMU. Note that coreboot apparently considers 5 years of backward compatibility enough. They supported both old and new method for finding cbfs that long. take care, Gerd ___ SeaBIOS mailing list -- seabios@seabios.org To unsubscribe send an email to seabios-le...@seabios.org
[SeaBIOS] Re: [PATCH v2 0/3] Add support for all HD and QXGA resolutions
On Thu, May 20, 2021 at 01:55:12PM -0400, Kevin O'Connor wrote: > On Tue, May 04, 2021 at 07:43:35PM -0400, Elliot Killick via SeaBIOS wrote: > > Hi, > > > > This patch series adds support for all HD and QXGA resolutions. > > > > I've taken Gerd's advice on the v1 patch and split the formatting > > improvments into a separate patch. > > > > I also tried to take Gerd's advice on removing some of the older colors > > depths for higher resolutions. However, upon doing this Windows was no > > longer recognizing some of the resolutions so I had to add them back. I > > split that up into a separate patch in case anyone wants to try and > > reproduce the issue. But, it should be fine to include those common > > color depths anyway for maximal compatibility. > > Thanks, and sorry for the delay in responding. > > In general it looks fine to me, but I was hoping Gerd could take a > look as well. Looks sane to me. > As one minor nit, I think it would be preferable to > squash patch 2 and 3 as it seems odd to remove the modes just to add > them back again. You mean squash 1+3 I guess? take care, Gerd ___ SeaBIOS mailing list -- seabios@seabios.org To unsubscribe send an email to seabios-le...@seabios.org
[SeaBIOS] Re: [PATCH] fw/coreboot.c: Use coreboot table to find cbfs
On Thu, May 20, 2021 at 06:09:55PM +, Peter Stuge wrote: > Arthur Heymans wrote: > > This breaks compatibility with very old coreboot build (build before > > fb5d5b16 "2015-07-14, cbtable: describe boot media"). > > Is that really acceptable in SeaBIOS master at some random time? As far I know there is no policy on that written down somewhere. In general we try avoid breaking backward compatibility (and thus requiring lockstep updates). But maintaining backward compatibility has a cost too, so this isn't set in stone. > > Keeping backward compatibility with the "cbfs master header" would > > complicate the code. > > Obviously, but is undeniably valuable, even if not to you. Well, maintaining compatibility with a version released more than five years ago isn't that valuable IMHO, but comes with the cost of adding compatibility code which most likely will never ever be actually used. > Proper advance notice of a breaking change allows others to invest > effort into coming up with a compatibility solution. Well. The compatible solution exists since 2015-07-14 ... take care, Gerd ___ SeaBIOS mailing list -- seabios@seabios.org To unsubscribe send an email to seabios-le...@seabios.org
[SeaBIOS] [PATCH] make BUILD_MIN_BIOSTABLE configurable
Add config option for BUILD_MIN_BIOSTABLE. Default is 8k for bios images being 256k or larger in size, 2k (current value) otherwise. Signed-off-by: Gerd Hoffmann --- Makefile | 2 +- scripts/layoutrom.py | 3 ++- src/Kconfig | 7 +++ 3 files changed, 10 insertions(+), 2 deletions(-) diff --git a/Makefile b/Makefile index 3d8943ef5f25..ddcd1dff399d 100644 --- a/Makefile +++ b/Makefile @@ -172,7 +172,7 @@ $(OUT)romlayout16.lds: $(OUT)ccode32flat.o $(OUT)code32seg.o $(OUT)ccode16.o $(O $(Q)$(OBJDUMP) -thr $(OUT)code32flat.o > $(OUT)code32flat.o.objdump $(Q)$(OBJDUMP) -thr $(OUT)code32seg.o > $(OUT)code32seg.o.objdump $(Q)$(OBJDUMP) -thr $(OUT)code16.o > $(OUT)code16.o.objdump - $(Q)$(PYTHON) ./scripts/layoutrom.py $(OUT)code16.o.objdump $(OUT)code32seg.o.objdump $(OUT)code32flat.o.objdump $(OUT)$(KCONFIG_AUTOHEADER) $(OUT)romlayout16.lds $(OUT)romlayout32seg.lds $(OUT)romlayout32flat.lds + $(Q)$(PYTHON) ./scripts/layoutrom.py $(OUT)code16.o.objdump $(OUT)code32seg.o.objdump $(OUT)code32flat.o.objdump $(OUT)$(KCONFIG_AUTOHEADER) $(OUT)romlayout16.lds $(OUT)romlayout32seg.lds $(OUT)romlayout32flat.lds $(CONFIG_MIN_BIOSTABLE) # These are actually built by scripts/layoutrom.py above, but by pulling them # into an extra rule we prevent make -j from spawning layoutrom.py 4 times. diff --git a/scripts/layoutrom.py b/scripts/layoutrom.py index 6616721d1b58..94deca9fcc85 100755 --- a/scripts/layoutrom.py +++ b/scripts/layoutrom.py @@ -636,7 +636,8 @@ def scanconfig(file): def main(): # Get output name -in16, in32seg, in32flat, cfgfile, out16, out32seg, out32flat = sys.argv[1:] +in16, in32seg, in32flat, cfgfile, out16, out32seg, out32flat, biostable = sys.argv[1:] +BUILD_MIN_BIOSTABLE = biostable * 1024 # Read in the objdump information infile16 = open(in16, 'r') diff --git a/src/Kconfig b/src/Kconfig index 3a8ffa15fded..95519fc50fa3 100644 --- a/src/Kconfig +++ b/src/Kconfig @@ -140,6 +140,13 @@ endchoice it into 128 KB (which was big enouth for a long time) you'll probably have to disable some featues such as xhci support. +config MIN_BIOSTABLE +int "biostable size (in KB)" +default 8 if ROM_SIZE >= 256 +default 2 +help +Memory space for BIOS tables in f-segment. + endmenu menu "Hardware support" -- 2.30.2 ___ SeaBIOS mailing list -- seabios@seabios.org To unsubscribe send an email to seabios-le...@seabios.org
[SeaBIOS] Re: SeaBIOS fails to boot from NVMe controller with lots of namespaces
Hi, > Regarding the failure cases, will things break during build > (BUILD_MIN_BIOSTABLE=16K), e.g: > > [seabios] Error! ROM doesn't fit (135584 > 131072) > [seabios]You have to either increase the size (CONFIG_ROM_SIZE) > [seabios]or turn off some features (such as hardware support not > [seabios]needed) to make it fit. Trying a more recent gcc version > [seabios]might work too. > [seabios] make: *** [out/bios.bin.prep] Error 1 > > Or do we expect undefined behavior at run time? Running out of memory can lead to undefined behavior at run time, depending on which allocations fail. Typical error pattern is that seabios can't initialize all devices, leading to boot failures. > 256 namespaces is not an insanely huge number. Well, back in the 80ies when the BIOS interfaces have been created 256 was an insanely huge number ... Given we have a number of real mode constrains for compatibility reasons (like some data structures must live in the f segment) there is no easy way out, we simply can't support an unlimited number of disks (which btw is one of the reasons why the "skip non-bootable disks" code exists). Of course there is the option to leave behind the 80ies and go for UEFI. take care, Gerd ___ SeaBIOS mailing list -- seabios@seabios.org To unsubscribe send an email to seabios-le...@seabios.org
[SeaBIOS] Re: SeaBIOS fails to boot from NVMe controller with lots of namespaces
Hi, > Is QEMU still shipping images limited to 128KiB? If so, that would be > another restriction. Ah, right, maybe that was the reason. Yes, there still is a 128k variant, for backward compatibility with qemu version 1.7 & older. Backward compatibility support for qemu version 1.3 & older has been removed already, so it could very well be that this will be deprecated and removed too soonish, but for now it is needed still. I guess that implies a config option is a good idea, so we can use different sizes for the 128k and the 256k version. take care, Gerd ___ SeaBIOS mailing list -- seabios@seabios.org To unsubscribe send an email to seabios-le...@seabios.org
[SeaBIOS] Re: SeaBIOS fails to boot from NVMe controller with lots of namespaces
Hi, > > > I changed the number of namespaces my controller reports to 1 and it > > > worked fine. Is there an easy way to get around this or do I have to > > > fix the code? I haven't looked at the code in detail, but I think we > > > don't have to allocate the array of namespaces in > > > nvme_controller_enable; instead, we can probe a namespace right before > > > we attempt to boot from it (not sure where exactly this is done). > > > > Well, you can try skip non-bootable namespaces and use "qemu -boot > > strict=on". It happens on nvme controller level already (see > > nvme_controller_setup()). > > AFAIK this applies to the entire controller, not individual namespaces. Current code, yes, but you can change the driver to do the same on namespace level (simliar to how virtio-scsi skips non-bootable disks) ... > > Easy way out without actual code changes would be to use two nvme > > controllers, one for the boot disk, one for all others, set bootindex for > > the > > boot disk only (and use strict=on of course). seabios should completely > > ignore the second nvme controller then. > > That's not option for me as this will be a customer VM so we don't know on > which NS the OS will be installed. ... except that it doesn't help much if you don't know which NS the OS is installed on. > In another email I said that increasing BUILD_MIN_BIOSTABLE by 8x solves the > problem, is there a problem with this solution? redhat increases BUILD_MIN_BIOSTABLE too (4x only though). I think this was discussed before but google doesn't find me anything so not sure why BUILD_MIN_BIOSTABLE hasn't been increased upstream. Maybe it doesn't work with some configurations due to running out of address space. Should that be the case a config option could be a way out. Kevin? take care, Gerd ___ SeaBIOS mailing list -- seabios@seabios.org To unsubscribe send an email to seabios-le...@seabios.org
[SeaBIOS] Re: [PATCH] vgasrc/svgamodes: added 4k resolution
Hi,
> > -#define VBE_DISPI_MAX_XRES 2560
> > -#define VBE_DISPI_MAX_YRES 1600
> > +#define VBE_DISPI_MAX_XRES 3840
> > +#define VBE_DISPI_MAX_YRES 2160
> > +{ 0x199, { MM_DIRECT, 3840, 2160, 32, 8, 16, SEG_GRAPH } },
> I'm not sure about this change. Is 3840x2160 a standard of some kind?
It is standard 4k (a comment saying that would be nice).
> Gerd - do you have any comments on this?
The edid spec also has 4096x2160 and 5120x2160, should we add those too
while being at it? Not sure which ones are actually used in practice
by monitors ...
Also: What about depths other than 32? I think we can safely ignore 24,
nothing modern uses that since at least a decade, so it should not be
relevant at all for 4k. 16bpp might be useful though.
take care,
Gerd
___
SeaBIOS mailing list -- seabios@seabios.org
To unsubscribe send an email to seabios-le...@seabios.org
[SeaBIOS] Re: SeaBIOS fails to boot from NVMe controller with lots of namespaces
On Thu, Apr 01, 2021 at 12:42:18PM +, Thanos Makatos wrote: > I'm using SeaBIOS (b0d61ec) to boot from a virtual NVMe controller that has > relatively many namespaces (64). The exact error is : > > /3ff9f000\ Start thread > |3ff9f000| Searching bootorder for: /pci@i0cf8/*@6 > ... > |3ff9f000| WARNING - Unable to allocate resource at > nvme_controller_enable:632! > > I changed the number of namespaces my controller reports to 1 and it > worked fine. Is there an easy way to get around this or do I have to > fix the code? I haven't looked at the code in detail, but I think we > don't have to allocate the array of namespaces in > nvme_controller_enable; instead, we can probe a namespace right before > we attempt to boot from it (not sure where exactly this is done). Well, you can try skip non-bootable namespaces and use "qemu -boot strict=on". It happens on nvme controller level already (see nvme_controller_setup()). Easy way out without actual code changes would be to use two nvme controllers, one for the boot disk, one for all others, set bootindex for the boot disk only (and use strict=on of course). seabios should completely ignore the second nvme controller then. HTH, Gerd ___ SeaBIOS mailing list -- seabios@seabios.org To unsubscribe send an email to seabios-le...@seabios.org
[SeaBIOS] Re: [PATCH] boot: add config option for fast device init
Hi,
> > > > Add a config option for fast device init (i.e. skip non-bootable
> > > > devices). This optimization breaks boot in some rare configurations,
> > > > specifically in case the boot loader needs access to secondary disks.
>
> Unfortunately, I missed the initial email due to seabios mailing list
> problems a few weeks ago.
Quote above is the commit message, actual patch below.
> What's the reason to add a config option for this setting? We
> typically make these choices at runtime using settings from fwcfg.
Well, there is a fwcfg setting already. Skipping non-bootable devices
happens only in case there is a HALT line in the fw_cfg bootorder file,
which translates to "-boot strict={on,off}" on the qemu command line.
Problem is that libvirt runs qemu with strict=on and provides no way to
request strict=off instead. Fixing that is on the way, but it'll take
some time as it affects not only libvirt itself but also the management
apps using libvirt.
So this patch allows to handles the reported regressions with a compile
time switch for the time being. If you don't like it, fine, we can
also carry the patch downstream for a while until libvirt & co are
fixed, it should only be needed temporarily after all.
I suspect we are not the only ones running into this though, so it might
be useful to have that upstream too ...
take care,
Gerd
-- cut here -
diff --git a/src/boot.c b/src/boot.c
index 1effd802ce06..771d2382e38f 100644
--- a/src/boot.c
+++ b/src/boot.c
@@ -299,6 +299,8 @@ u8 is_bootprio_strict(void)
{
static int prio_halt = -2;
+if (!CONFIG_BOOT_FAST_INIT)
+return 0;
if (prio_halt == -2)
prio_halt = find_prio("HALT");
return prio_halt >= 0;
diff --git a/src/Kconfig b/src/Kconfig
index 3a8ffa15fded..6b750a41b42c 100644
--- a/src/Kconfig
+++ b/src/Kconfig
@@ -72,6 +72,16 @@ endchoice
help
Support controlling of the boot order via the fw_cfg/CBFS
"bootorder" file.
+config BOOT_FAST_INIT
+depends on BOOTORDER
+bool "Fast boot device init"
+default y
+help
+Skip initialization for devices without bootindex. Speeds
+up boot and reduced memory footprint, but may cause boot
+problems in case the bootloader needs access to secondary
+disks.
+
config HOST_BIOS_GEOMETRY
depends on BOOT
bool "Boot device bios geometry override"
___
SeaBIOS mailing list -- seabios@seabios.org
To unsubscribe send an email to seabios-le...@seabios.org
[SeaBIOS] Re: seabios unable to boot from iscsi disk in a vm with 11 virtio disks and 1 iscsi disk.
> |7ffa7000| WARNING - Unable to allocate resource at vp_find_vq:301! > I wonder how can I diagnose this problem and how to deal with? seabios runs out of memory. You can try update to 1.14 and use "qemu -boot strict=on". seabios will only initialize devices with bootindex then, which should reduce the amount of memory needed to manage disks. HTH, Gerd ___ SeaBIOS mailing list -- seabios@seabios.org To unsubscribe send an email to seabios-le...@seabios.org
[SeaBIOS] Re: [PATCH] boot: add config option for fast device init
On Tue, Mar 23, 2021 at 04:31:41PM +0100, Paul Menzel wrote: > Dear Gerd, > > > On 2021-03-23 15:18, Gerd Hoffmann wrote: > > Add a config option for fast device init (i.e. skip non-bootable > > devices). This optimization breaks boot in some rare configurations, > > specifically in case the boot loader needs access to secondary disks. > > Thank you for the patch. Could you please elaborate and describe your > test setup and how much the boot time is decreased? Have no numbers. Note that optimization is already in 1.14 and this only adds a config option to turn it *off*. take care, Gerd ___ SeaBIOS mailing list -- seabios@seabios.org To unsubscribe send an email to seabios-le...@seabios.org
[SeaBIOS] [PATCH] boot: add config option for fast device init
Add a config option for fast device init (i.e. skip non-bootable
devices). This optimization breaks boot in some rare configurations,
specifically in case the boot loader needs access to secondary disks.
Signed-off-by: Gerd Hoffmann
---
src/boot.c | 2 ++
src/Kconfig | 10 ++
2 files changed, 12 insertions(+)
diff --git a/src/boot.c b/src/boot.c
index 1effd802ce06..771d2382e38f 100644
--- a/src/boot.c
+++ b/src/boot.c
@@ -299,6 +299,8 @@ u8 is_bootprio_strict(void)
{
static int prio_halt = -2;
+if (!CONFIG_BOOT_FAST_INIT)
+return 0;
if (prio_halt == -2)
prio_halt = find_prio("HALT");
return prio_halt >= 0;
diff --git a/src/Kconfig b/src/Kconfig
index 3a8ffa15fded..6b750a41b42c 100644
--- a/src/Kconfig
+++ b/src/Kconfig
@@ -72,6 +72,16 @@ endchoice
help
Support controlling of the boot order via the fw_cfg/CBFS
"bootorder" file.
+config BOOT_FAST_INIT
+depends on BOOTORDER
+bool "Fast boot device init"
+default y
+help
+Skip initialization for devices without bootindex. Speeds
+up boot and reduced memory footprint, but may cause boot
+problems in case the bootloader needs access to secondary
+disks.
+
config HOST_BIOS_GEOMETRY
depends on BOOT
bool "Boot device bios geometry override"
--
2.30.2
___
SeaBIOS mailing list -- seabios@seabios.org
To unsubscribe send an email to seabios-le...@seabios.org
[SeaBIOS] Re: How to boot from DVD/CD automatically, instead of pressing a key by hand?
On Sun, Feb 28, 2021 at 02:22:53PM -, Yiguang Chen wrote: > Most time, When a vm with seabios start. The bios will display such info: > - > Seabios (version rel-1.13-0 ..) > Machine UUID ... > > IPXE .. > > IPXE.. > > Booting from DVD/CD... > Press any key to boot from CD or DVD. > --- > > It means that have a bootable cdrom to boot. But If we want to boot > from cdrom, we must press any key as what the warning had said. If it > is possible to boot from DVD/CD automatically, instead of pressing a > key by hand? This is a windows install iso, right? This isn't seabios, the windows boot loader does that. I think windows does this only in case it finds a bootable hard disk. So when booting the guest with a fresh & blank virtual hard disk it should boot the windows installer without asking for a key press. HTH, Gerd ___ SeaBIOS mailing list -- seabios@seabios.org To unsubscribe send an email to seabios-le...@seabios.org
