February 2017 - SeaBIOS - mail.coreboot.org

[PATCH 0/3] SeaVGABIOS serial console test
by Kevin O'Connor Sept. 5, 2017

Sept. 5, 2017

Hi Gerd, I was curious to see what the "sercon" stuff would look like in SeaVGABIOS instead of in SeaBIOS. So, I put together a quick prototype. The code is also at: https://github.com/KevinOConnor/seabios/tree/testing This is just a proof-of-concept thing - I didn't implement any of the useful features you have in your series. Specifically, it doesn't unclutter the serial output, doesn't implement cp437 translations, and doesn't handle multi-byte input. It does does have basic input, output, and split-output handling though. I'm not sure if this is better than a SeaBIOS implementation. I suspect it will be easier to handle vga quirks this way. However, handling exotic serial outputs (eg, mmio and usb based) would be better suited in SeaBIOS. Thoughts? -Kevin Kevin O'Connor (3): sercon: Initial support for VGA emulation over serial port sercon: Add basic keyboard input support sercon: Support "split output" mode Makefile | 2 +- vgasrc/Kconfig | 6 + vgasrc/sercon.c | 356 ++++++++++++++++++++++++++++++++++++++++++++++++++++++ vgasrc/vgabios.c | 15 ++- vgasrc/vgabios.h | 5 + vgasrc/vgaentry.S | 7 ++ vgasrc/vgahw.h | 72 ++++++++++- vgasrc/vgainit.c | 12 +- vgasrc/vgautil.h | 24 ++++ 9 files changed, 482 insertions(+), 17 deletions(-) create mode 100644 vgasrc/sercon.c -- 2.5.5

2 12

NVMe 1.0 compatibility and fixes
by Daniel Verkamp March 5, 2017

March 5, 2017

With the first two patches applied, I am able to install and boot FreeDOS on an Intel SSD DC P3700, an NVMe 1.0 device, in QEMU using PCI device assignment. The rest of the patches are minor issues found through inspection.

4 11

varlow/extrastack vs code
by Dr. David Alan Gilbert Feb. 27, 2017

Feb. 27, 2017

Hi, I turned the debug level up to 4 on our smaller (128k) ROM downstream build and seem to have hit a case where it's been layed out so that the 'ExtraStack' is at the same location as some code (display_uuid) which was causing some very random behaviour; from an objdump disassemble of the rom.o that was produced: ef79d: f3 ab rep stos %eax,%es:(%edi) ef79f: 8d 43 08 lea 0x8(%ebx),%eax ef7a2: b1 10 mov $0x10,%cl ef7a4: 8d 54 24 74 lea 0x74(%esp),%edx ef7a8: e8 50 46 ff ff call e3dfd <memcmp> ef7ad: 85 c0 test %eax,%eax ef7af: 0f 84 33 01 00 00 je ef8e8 <ExtraStack+0x110> ef7b5: 8b 15 0c 23 0f 00 mov 0xf230c,%edx ef7bb: 80 7a 06 02 cmpb $0x2,0x6(%edx) ef7bf: 0f b6 43 17 movzbl 0x17(%ebx),%eax ef7c3: 77 0c ja ef7d1 <StackPos+0x1> ef7c5: 0f 85 80 00 00 00 jne ef84b <ExtraStack+0x73> ef7cb: 80 7a 07 05 cmpb $0x5,0x7(%edx) ef7cf: 76 7a jbe ef84b <ExtraStack+0x73> Note the 'ExtraStack+...' where as a few lines before it's maininit for other jumps, then looking at a sorted output of the rom.o.objdump: 000eddf2 l F .text 000000e0 virtio_scsi_add_lun.constprop.113 000eded2 l F .text 0000080d device_hardware_setup 000ee6df l F .text 00001a17 maininit <------------- 000ef790 g *ABS* 00000000 final_varlow_start 000ef790 g O *ABS* 00000004 BootSequence 000ef794 g O *ABS* 00000001 FloppyDOR 000ef798 g O *ABS* 00000008 LastUSBkey 000ef7a0 g O *ABS* 00000001 Ps2ctr 000ef7a4 g O *ABS* 00000004 RTCusers 000ef7a8 g O *ABS* 00000004 TimerLast 000ef7ac g O *ABS* 00000001 HaveAttemptedReboot 000ef7ad g O *ABS* 00000001 Century 000ef7b0 g O *ABS* 00000010 CDRom_locks 000ef7c0 g O *ABS* 00000010 DefaultDPTE 000ef7d0 g O *ABS* 00000004 StackPos 000ef7d8 g O *ABS* 00000801 ExtraStack <------------- 000effdc g O *ABS* 00000018 Call16Data 000f0000 g *ABS* 00000000 final_readonly_start 000f0000 g *ABS* 00000000 zonefseg_start 000f00f6 g F .text 0000038b dopost 000f0481 g F .text 000001c2 handle_pmm 000f0644 l O .text 00000014 CSWTCH.1353 000f0658 l O .text 00000014 __func__.14607 000f066c l O .text 00000011 __func__.14624 000f0680 l O .text 00000010 __func__.14549 000f0690 l O .text 0000000b __func__.14497 What's supposed to stop that happening? I'd chosen a debug level of 4 since that was the largest it would go without the build complaining it wouldn't fit, so I thought I was safe since something did complain if it got way too big. (This is based off 1.9.1) Dave -- Dr. David Alan Gilbert / dgilbert(a)redhat.com / Manchester, UK

5 39

Stable seabios release
by Kevin O'Connor Feb. 24, 2017

Feb. 24, 2017

On Tue, Feb 21, 2017 at 08:10:57AM +0100, Gerd Hoffmann wrote: > Hi, > > > Gerd - are you planning to backport this series to the stable branch? > > Yes. Unless we'll have a 1.11 release next week, which I doubt ;) No short term plans for a major release. You may want to consider the following additional patches for the next stable release: 106543de - ahci: Set upper 32-bit registers to zero 970af16e - vgasrc: Increase debug level dbf9dd27 - ps2port: Disable keyboard/mouse prior to resetting ps2 controller -Kevin

3 2

Make it possible to boot encrypted HDDs when using seabios as payload on coreboot
by i1w5d7gf38keg＠tutanota.com Feb. 22, 2017

Feb. 22, 2017

I liked to try out seabios instead of grub as payload and after flashing a coreboot image with seabios as only payload i got the message that i cant find any bootable device. Seems like seabios cant boot a basic debian installation where you encrypt the hdd and write grub into the MBR - the most default configuration. I have search trough the last months seabios mailing list archives but cant find a talk about that. Are there any plans of adding support for this?

2 1

[PATCH v7 0/5] QEMU: Add capability to write back fw_cfg address to QEMU
by ben＠skyportsystems.com Feb. 21, 2017

Feb. 21, 2017

From: Ben Warren <ben(a)skyportsystems.com> This patch set adds the capability to write to QEMU across the fw_cfg DMA link. It adds a higher-level command to write the BIOS-allocated address of one fw_cfg file into an arbitrary point within another, writeable fw_cfg file across the above-mentioned link. The initial use case is for Windows VM Generation ID, where QEMU needs to change the contents of fw_cfg data at runtime, while still having BIOS allocate and manage the memory. The final corresponding QEMU patch can be found here: https://www.mail-archive.com/qemu-devel@nongnu.org/msg430490.html v6->v7: - minor refactoring of qemu_cfg_write_file* functions v5->v6: - Rebased to top-of-tree - Minor refactoring and conditional execution based on code review v4->v5: - Minor changes to range checking and data validation - Added code for replaying COMMAND_WRITE_POINTER commands on S3 resume v3->v4: - Added a 'src_offset' field in the message so the pointer need not point to the beginning of the file. - Changed the command struct definitions from anonymous to named. v2->v3: - fixed up the qemu_cfg_write* functions to allow writing to an arbitrary offset within the destination file. - Changed function name to COMMAND_WRITE_POINTER and its functionality to not patch memory at all, but write back to a specified offset. v1->v2: - separated patch into two functional units. - changed so writes only occur over the DMA interface. - fixed coding style. - removed change to romfile struct definition (removed new write_back method). Ben Warren (5): QEMU DMA: Add DMA write capability romfile-loader: Switch to using named structs QEMU fw_cfg: Add command to write back address of file QEMU fw_cfg: Add functions for accessing files by key QEMU fw_cfg: Write fw_cfg back on S3 resume src/fw/paravirt.c | 68 +++++++++++++++++++++++++++++ src/fw/paravirt.h | 5 +++ src/fw/romfile_loader.c | 112 ++++++++++++++++++++++++++++++++++++++++-------- src/fw/romfile_loader.h | 65 ++++++++++++++++++---------- src/resume.c | 4 ++ 5 files changed, 214 insertions(+), 40 deletions(-) -- 2.7.4

3 7

Re: [SeaBIOS] [PATCH v7 5/5] QEMU fw_cfg: Write fw_cfg back on S3 resume
by Kevin O'Connor Feb. 21, 2017

Feb. 21, 2017

On Mon, Feb 20, 2017 at 07:56:19PM -0800, ben(a)skyportsystems.com wrote: > From: Ben Warren <ben(a)skyportsystems.com> > > Any pointers to BIOS-allocated memory that were written back to QEMU > fw_cfg files are replayed when resuming from S3 sleep. > > Signed-off-by: Ben Warren <ben(a)skyportsystems.com> > Reviewed-by: Laszlo Ersek <lersek(a)redhat.com> > --- > src/fw/romfile_loader.c | 33 +++++++++++++++++++++++++++++++++ > src/fw/romfile_loader.h | 2 ++ > src/resume.c | 4 ++++ > 3 files changed, 39 insertions(+) > > diff --git a/src/fw/romfile_loader.c b/src/fw/romfile_loader.c > index 30e7b58..14bc908 100644 > --- a/src/fw/romfile_loader.c > +++ b/src/fw/romfile_loader.c > @@ -4,6 +4,7 @@ > #include "string.h" // strcmp > #include "romfile.h" // struct romfile_s > #include "malloc.h" // Zone*, _malloc > +#include "list.h" // struct hlist_node > #include "output.h" // warn_* > #include "paravirt.h" // qemu_cfg_write_file > > @@ -16,6 +17,16 @@ struct romfile_loader_files { > struct romfile_loader_file files[]; > }; > > +// Data structures for storing "write pointer" entries for possible replay > +struct romfile_wr_pointer_entry { > + u64 pointer; > + u32 offset; > + u16 key; > + u8 ptr_size; > + struct hlist_node node; > +}; > +static struct hlist_head romfile_pointer_list; > + > static struct romfile_loader_file * > romfile_loader_find(const char *name, > struct romfile_loader_files *files) > @@ -29,6 +40,19 @@ romfile_loader_find(const char *name, > return NULL; > } > > +// Replay "write pointer" entries back to QEMU > +void romfile_fw_cfg_resume(void) > +{ > + if (!CONFIG_QEMU) > + return; > + > + struct romfile_wr_pointer_entry *entry; > + hlist_for_each_entry(entry, &romfile_pointer_list, node) { > + qemu_cfg_write_file_simple(&entry->pointer, entry->key, > + entry->offset, entry->ptr_size); > + } > +} > + > static void romfile_loader_allocate(struct romfile_loader_entry_s *entry, > struct romfile_loader_files *files) > { > @@ -163,6 +187,15 @@ static void romfile_loader_write_pointer(struct romfile_loader_entry_s *entry, > entry->wr_pointer.size) != entry->wr_pointer.size) { > goto err; > } > + > + /* Store the info so it can replayed later if necessary */ > + struct romfile_wr_pointer_entry *store = malloc_high(sizeof(*store)); > + store->pointer = pointer; I missed this in my earlier review - it's necessary to always check the return of malloc() in seabios. (Writing to NULL changes memory at address 0 which is shared with the 16bit interrupt table.) I fixed it upon commit. -Kevin

1 0

Re: [SeaBIOS] [PATCH v7 5/5] QEMU fw_cfg: Write fw_cfg back on S3 resume
by Igor Mammedov Feb. 21, 2017

Feb. 21, 2017

On Mon, 20 Feb 2017 19:56:19 -0800 ben(a)skyportsystems.com wrote: > From: Ben Warren <ben(a)skyportsystems.com> > > Any pointers to BIOS-allocated memory that were written back to QEMU > fw_cfg files are replayed when resuming from S3 sleep. > > Signed-off-by: Ben Warren <ben(a)skyportsystems.com> > Reviewed-by: Laszlo Ersek <lersek(a)redhat.com> Reviewed-by: Igor Mammedov <imammedo(a)redhat.com> > --- > src/fw/romfile_loader.c | 33 +++++++++++++++++++++++++++++++++ > src/fw/romfile_loader.h | 2 ++ > src/resume.c | 4 ++++ > 3 files changed, 39 insertions(+) > > diff --git a/src/fw/romfile_loader.c b/src/fw/romfile_loader.c > index 30e7b58..14bc908 100644 > --- a/src/fw/romfile_loader.c > +++ b/src/fw/romfile_loader.c > @@ -4,6 +4,7 @@ > #include "string.h" // strcmp > #include "romfile.h" // struct romfile_s > #include "malloc.h" // Zone*, _malloc > +#include "list.h" // struct hlist_node > #include "output.h" // warn_* > #include "paravirt.h" // qemu_cfg_write_file > > @@ -16,6 +17,16 @@ struct romfile_loader_files { > struct romfile_loader_file files[]; > }; > > +// Data structures for storing "write pointer" entries for possible replay > +struct romfile_wr_pointer_entry { > + u64 pointer; > + u32 offset; > + u16 key; > + u8 ptr_size; > + struct hlist_node node; > +}; > +static struct hlist_head romfile_pointer_list; > + > static struct romfile_loader_file * > romfile_loader_find(const char *name, > struct romfile_loader_files *files) > @@ -29,6 +40,19 @@ romfile_loader_find(const char *name, > return NULL; > } > > +// Replay "write pointer" entries back to QEMU > +void romfile_fw_cfg_resume(void) > +{ > + if (!CONFIG_QEMU) > + return; > + > + struct romfile_wr_pointer_entry *entry; > + hlist_for_each_entry(entry, &romfile_pointer_list, node) { > + qemu_cfg_write_file_simple(&entry->pointer, entry->key, > + entry->offset, entry->ptr_size); > + } > +} > + > static void romfile_loader_allocate(struct romfile_loader_entry_s *entry, > struct romfile_loader_files *files) > { > @@ -163,6 +187,15 @@ static void romfile_loader_write_pointer(struct romfile_loader_entry_s *entry, > entry->wr_pointer.size) != entry->wr_pointer.size) { > goto err; > } > + > + /* Store the info so it can replayed later if necessary */ > + struct romfile_wr_pointer_entry *store = malloc_high(sizeof(*store)); > + store->pointer = pointer; > + store->key = qemu_get_romfile_key(dest_file); > + store->offset = dst_offset; > + store->ptr_size = entry->wr_pointer.size; > + hlist_add_head(&store->node, &romfile_pointer_list); > + > return; > err: > warn_internalerror(); > diff --git a/src/fw/romfile_loader.h b/src/fw/romfile_loader.h > index 4dc50ab..fcd4ab2 100644 > --- a/src/fw/romfile_loader.h > +++ b/src/fw/romfile_loader.h > @@ -86,4 +86,6 @@ enum { > > int romfile_loader_execute(const char *name); > > +void romfile_fw_cfg_resume(void); > + > #endif > diff --git a/src/resume.c b/src/resume.c > index e67cfce..99fa34f 100644 > --- a/src/resume.c > +++ b/src/resume.c > @@ -17,6 +17,7 @@ > #include "string.h" // memset > #include "util.h" // dma_setup > #include "tcgbios.h" // tpm_s3_resume > +#include "fw/romfile_loader.h" // romfile_fw_cfg_resume > > // Handler for post calls that look like a resume. > void VISIBLE16 > @@ -105,6 +106,9 @@ s3_resume(void) > tpm_s3_resume(); > s3_resume_vga(); > > + /* Replay any fw_cfg entries that go back to the host */ > + romfile_fw_cfg_resume(); > + > make_bios_readonly(); > > // Invoke the resume vector.

1 0

Re: [SeaBIOS] [PATCH v7 4/5] QEMU fw_cfg: Add functions for accessing files by key
by Laszlo Ersek Feb. 21, 2017

Feb. 21, 2017

On 02/21/17 04:56, ben(a)skyportsystems.com wrote: > From: Ben Warren <ben(a)skyportsystems.com> > > Due to memory contraints, when resuming from S3 the fw_cfg "files" API > isn't available. This adds a simple API to get a file 'key', and to > write to the file using the key as a reference. > > Signed-off-by: Ben Warren <ben(a)skyportsystems.com> > Reviewed-by: Igor Mammedov <imammedo(a)redhat.com> > Reviewed-by: Laszlo Ersek <lersek(a)redhat.com> > --- > src/fw/paravirt.c | 41 ++++++++++++++++++++++++++++++----------- > src/fw/paravirt.h | 2 ++ > 2 files changed, 32 insertions(+), 11 deletions(-) Yep, looks good, my R-b stands. Thanks, Laszlo > diff --git a/src/fw/paravirt.c b/src/fw/paravirt.c > index 4618647..707502d 100644 > --- a/src/fw/paravirt.c > +++ b/src/fw/paravirt.c > @@ -329,6 +329,22 @@ qemu_cfg_read_file(struct romfile_s *file, void *dst, u32 maxlen) > return file->size; > } > > +// Bare-bones function for writing a file knowing only its unique > +// identifying key (select) > +int > +qemu_cfg_write_file_simple(void *src, u16 key, u32 offset, u32 len) > +{ > + if (offset == 0) { > + /* Do it in one transfer */ > + qemu_cfg_write_entry(src, key, len); > + } else { > + qemu_cfg_select(key); > + qemu_cfg_skip(offset); > + qemu_cfg_write(src, len); > + } > + return len; > +} > + > int > qemu_cfg_write_file(void *src, struct romfile_s *file, u32 offset, u32 len) > { > @@ -339,17 +355,8 @@ qemu_cfg_write_file(void *src, struct romfile_s *file, u32 offset, u32 len) > warn_internalerror(); > return -1; > } > - struct qemu_romfile_s *qfile; > - qfile = container_of(file, struct qemu_romfile_s, file); > - if (offset == 0) { > - /* Do it in one transfer */ > - qemu_cfg_write_entry(src, qfile->select, len); > - } else { > - qemu_cfg_select(qfile->select); > - qemu_cfg_skip(offset); > - qemu_cfg_write(src, len); > - } > - return len; > + return qemu_cfg_write_file_simple(src, qemu_get_romfile_key(file), > + offset, len); > } > > static void > @@ -370,6 +377,18 @@ qemu_romfile_add(char *name, int select, int skip, int size) > } > > u16 > +qemu_get_romfile_key(struct romfile_s *file) > +{ > + struct qemu_romfile_s *qfile; > + if (file->copy != qemu_cfg_read_file) { > + warn_internalerror(); > + return 0; > + } > + qfile = container_of(file, struct qemu_romfile_s, file); > + return qfile->select; > +} > + > +u16 > qemu_get_present_cpus_count(void) > { > u16 smp_count = 0; > diff --git a/src/fw/paravirt.h b/src/fw/paravirt.h > index fb220d8..16f3d9a 100644 > --- a/src/fw/paravirt.h > +++ b/src/fw/paravirt.h > @@ -56,5 +56,7 @@ void qemu_cfg_init(void); > > u16 qemu_get_present_cpus_count(void); > int qemu_cfg_write_file(void *src, struct romfile_s *file, u32 offset, u32 len); > +int qemu_cfg_write_file_simple(void *src, u16 key, u32 offset, u32 len); > +u16 qemu_get_romfile_key(struct romfile_s *file); > > #endif >

1 0

Re: [SeaBIOS] [PATCH v6 4/5] QEMU fw_cfg: Add functions for accessing files by key
by Laszlo Ersek Feb. 20, 2017

Feb. 20, 2017

On 02/20/17 21:14, ben(a)skyportsystems.com wrote: > From: Ben Warren <ben(a)skyportsystems.com> > > Due to memory contraints, when resuming from S3 the fw_cfg "files" API > isn't available. This adds a simple API to get a file 'key', and to > write to the file using the key as a reference. > > Signed-off-by: Ben Warren <ben(a)skyportsystems.com> > --- > src/fw/paravirt.c | 32 ++++++++++++++++++++++++++------ > src/fw/paravirt.h | 2 ++ > 2 files changed, 28 insertions(+), 6 deletions(-) > > diff --git a/src/fw/paravirt.c b/src/fw/paravirt.c > index 4618647..225b08b 100644 > --- a/src/fw/paravirt.c > +++ b/src/fw/paravirt.c > @@ -329,6 +329,17 @@ qemu_cfg_read_file(struct romfile_s *file, void *dst, u32 maxlen) > return file->size; > } > > +// Bare-bones function for writing a file knowing only its unique > +// identifying key (select) > +int > +qemu_cfg_write_file_simple(void *src, u16 key, u32 offset, u32 len) > +{ > + qemu_cfg_select(key); > + qemu_cfg_skip(offset); > + qemu_cfg_write(src, len); > + return len; > +} > + > int > qemu_cfg_write_file(void *src, struct romfile_s *file, u32 offset, u32 len) > { > @@ -339,15 +350,12 @@ qemu_cfg_write_file(void *src, struct romfile_s *file, u32 offset, u32 len) > warn_internalerror(); > return -1; > } > - struct qemu_romfile_s *qfile; > - qfile = container_of(file, struct qemu_romfile_s, file); > + u16 key = qemu_get_romfile_key(file); > if (offset == 0) { > /* Do it in one transfer */ > - qemu_cfg_write_entry(src, qfile->select, len); > + qemu_cfg_write_entry(src, key, len); > } else { > - qemu_cfg_select(qfile->select); > - qemu_cfg_skip(offset); > - qemu_cfg_write(src, len); > + qemu_cfg_write_file_simple(src, key, offset, len); > } > return len; > } One of the ideas that I mentioned here was to move not just the second branch of the "if" to qemu_cfg_write_file_simple(), but the entire "if" -- both branches. Because, qemu_cfg_write_entry() looks suitable for S3 too, and if that kind of optimization makes sense for normal boot, then it makes sense for S3 resume as well. Anyway, this is not a functional problem, I won't obsess about it. Reviewed-by: Laszlo Ersek <lersek(a)redhat.com> Thanks Laszlo > @@ -370,6 +378,18 @@ qemu_romfile_add(char *name, int select, int skip, int size) > } > > u16 > +qemu_get_romfile_key(struct romfile_s *file) > +{ > + struct qemu_romfile_s *qfile; > + if (file->copy != qemu_cfg_read_file) { > + warn_internalerror(); > + return 0; > + } > + qfile = container_of(file, struct qemu_romfile_s, file); > + return qfile->select; > +} > + > +u16 > qemu_get_present_cpus_count(void) > { > u16 smp_count = 0; > diff --git a/src/fw/paravirt.h b/src/fw/paravirt.h > index fb220d8..16f3d9a 100644 > --- a/src/fw/paravirt.h > +++ b/src/fw/paravirt.h > @@ -56,5 +56,7 @@ void qemu_cfg_init(void); > > u16 qemu_get_present_cpus_count(void); > int qemu_cfg_write_file(void *src, struct romfile_s *file, u32 offset, u32 len); > +int qemu_cfg_write_file_simple(void *src, u16 key, u32 offset, u32 len); > +u16 qemu_get_romfile_key(struct romfile_s *file); > > #endif >

2 1