SeaBIOS

seabios@seabios.org

3783 discussions

[PATCH] cbvga_set_mode: refine clear display logic
by Gerd Hoffmann 27 Jun '18

27 Jun '18

There is no need to skip text mode clearing. Clearing the framebuffer should be safe on legacy calls too. Signed-off-by: Gerd Hoffmann <kraxel(a)redhat.com> --- vgasrc/cbvga.c | 18 ++++++++++-------- 1 file changed, 10 insertions(+), 8 deletions(-) diff --git a/vgasrc/cbvga.c b/vgasrc/cbvga.c index f6ebe71242..859524cb23 100644 --- a/vgasrc/cbvga.c +++ b/vgasrc/cbvga.c @@ -201,18 +201,20 @@ cbvga_set_mode(struct vgamode_s *vmode_g, int flags) */ u8 extra_stack = GET_BDA_EXT(flags) & BF_EXTRA_STACK; MASK_BDA_EXT(flags, BF_EMULATE_TEXT, emul ? BF_EMULATE_TEXT : 0); - if (!(flags & MF_NOCLEARMEM) && extra_stack) { + if (!(flags & MF_NOCLEARMEM)) { if (GET_GLOBAL(CBmodeinfo.memmodel) == MM_TEXT) { memset16_far(SEG_CTEXT, (void*)0, 0x0720, 80*25*2); return 0; } - struct gfx_op op; - init_gfx_op(&op, &CBmodeinfo); - op.x = op.y = 0; - op.xlen = GET_GLOBAL(CBmodeinfo.width); - op.ylen = GET_GLOBAL(CBmodeinfo.height); - op.op = GO_MEMSET; - handle_gfx_op(&op); + if (extra_stack || flags & MF_LEGACY) { + struct gfx_op op; + init_gfx_op(&op, &CBmodeinfo); + op.x = op.y = 0; + op.xlen = GET_GLOBAL(CBmodeinfo.width); + op.ylen = GET_GLOBAL(CBmodeinfo.height); + op.op = GO_MEMSET; + handle_gfx_op(&op); + } } return 0; } -- 2.9.3

3 4

Re: [SeaBIOS] [PATCH v2 6/6] cbvga_set_mode: disable clearmem in windows x86 emulator.
by Patrick Rudolph 26 Jun '18

26 Jun '18

On Mon, 2018-06-04 at 09:31 -0400, Kevin O'Connor wrote: > On Mon, Jun 04, 2018 at 09:29:17AM +0200, Gerd Hoffmann wrote: > > Signed-off-by: Gerd Hoffmann <kraxel(a)redhat.com> > > --- > > vgasrc/cbvga.c | 10 +++++++++- > > 1 file changed, 9 insertions(+), 1 deletion(-) > > > > diff --git a/vgasrc/cbvga.c b/vgasrc/cbvga.c > > index 3f16bee10c..f6ebe71242 100644 > > --- a/vgasrc/cbvga.c > > +++ b/vgasrc/cbvga.c > > @@ -192,8 +192,16 @@ int > > cbvga_set_mode(struct vgamode_s *vmode_g, int flags) > > { > > u8 emul = vmode_g == &CBemulinfo || GET_GLOBAL(CBmode) == 0x03; > > + /* > > + * The extra_stack flag is false when running in windows x86 > > + * emulator, to avoid stack switching triggering bugs. Using the > > + * same flag here to skip screen clearing, because the windows > > + * emulator seems to have problems to handle the int 1587 call > > + * too, and GO_MEMSET uses that. > > + */ > > + u8 extra_stack = GET_BDA_EXT(flags) & BF_EXTRA_STACK; > > MASK_BDA_EXT(flags, BF_EMULATE_TEXT, emul ? BF_EMULATE_TEXT : 0); > > - if (!(flags & MF_NOCLEARMEM)) { > > + if (!(flags & MF_NOCLEARMEM) && extra_stack) { > > FYI, extra_stack will only be true if CONFIG_VGA_ALLOCATE_EXTRA_STACK > is set, but I guess that's okay. > > Thanks, the series looks good to me. > -Kevin This commit breaks SeaBIOS' menu when used with coreboot's native graphic init in text mode. Payloads are not affacted (tested NTLDR and coreinfo). Everything works fine with native graphic init in high resolution framebuffer mode. I've got no debug log at hand, but I'll investigate asap. Tested on Lenovo T500 using libgfxinit with latest coreboot master. Regards, Patrick > > _______________________________________________ > SeaBIOS mailing list > SeaBIOS(a)seabios.org > https://mail.coreboot.org/mailman/listinfo/seabios

3 3

Re: [SeaBIOS] [PATCH v2 6/6] cbvga_set_mode: disable clearmem in windows x86 emulator.
by Patrick Rudolph 23 Jun '18

23 Jun '18

On Fri, 2018-06-22 at 10:14 -0400, Kevin O'Connor wrote: > On Fri, Jun 22, 2018 at 08:42:50AM +0200, Gerd Hoffmann wrote: > > On Wed, Jun 20, 2018 at 08:00:28PM +0200, Patrick Rudolph wrote: > > > This commit breaks SeaBIOS' menu when used with coreboot's native > > > graphic init in text mode. Payloads are not affacted (tested NTLDR and > > > coreinfo). > > > Everything works fine with native graphic init in high resolution > > > framebuffer mode. I've got no debug log at hand, but I'll investigate > > > asap. > > > Tested on Lenovo T500 using libgfxinit with latest coreboot master. > > > > Hmm, no clue what could cause this. But clearing the memory is only > > problematic for the framebuffer case, so maybe the patch below helps? > > > > diff --git a/vgasrc/cbvga.c b/vgasrc/cbvga.c > > index f6ebe71242..a48f4dc885 100644 > > --- a/vgasrc/cbvga.c > > +++ b/vgasrc/cbvga.c > > @@ -201,18 +201,20 @@ cbvga_set_mode(struct vgamode_s *vmode_g, int flags) > > */ > > u8 extra_stack = GET_BDA_EXT(flags) & BF_EXTRA_STACK; > > MASK_BDA_EXT(flags, BF_EMULATE_TEXT, emul ? BF_EMULATE_TEXT : 0); > > - if (!(flags & MF_NOCLEARMEM) && extra_stack) { > > + if (!(flags & MF_NOCLEARMEM)) { > > if (GET_GLOBAL(CBmodeinfo.memmodel) == MM_TEXT) { > > memset16_far(SEG_CTEXT, (void*)0, 0x0720, 80*25*2); > > return 0; > > } > > - struct gfx_op op; > > - init_gfx_op(&op, &CBmodeinfo); > > - op.x = op.y = 0; > > - op.xlen = GET_GLOBAL(CBmodeinfo.width); > > - op.ylen = GET_GLOBAL(CBmodeinfo.height); > > - op.op = GO_MEMSET; > > - handle_gfx_op(&op); > > + if (extra_stack) { > > I'm also not sure on the cause, but I think it should be safe to > change this to: > > if (extra_stack || flags & MF_LEGACY) { > Seems to be the correct solution, as BF_EXTRA_STACK is set after cbvga_set_mode and thus extra_stack is 0 on first cbvga_set_mode call. > because if this is a legacy call then it should be safe to write to > highmem even if the last call was a vesa modeset. > > -Kevin

1 0

[PATCH v2 0/3] qemu: add qemu ramfb support
by Gerd Hoffmann 20 Jun '18

20 Jun '18

Hi, Second version of the ramfb series. Turned out the previous version didn't work at all, appearently I've tested by accident with an older rom version which had a copy of the fw_cfg code instead of linking paravirt.o. Making the linked paravirt.o work turned out to be difficuilt due to dependencies on stuff like threads which isn't present in the vgabios builds. So I'm back to the version with the (stripped down) copy of the fw_cfg code ... Gerd Hoffmann (3): pmm: use tmp zone on oom vgasrc: add allocate_pmm() qemu: add qemu ramfb support Makefile | 2 +- vgasrc/vgahw.h | 28 +++++----- vgasrc/vgautil.h | 4 ++ src/pmm.c | 13 +++++ vgasrc/ramfb.c | 163 +++++++++++++++++++++++++++++++++++++++++++++++++++++++ vgasrc/vgainit.c | 48 ++++++++++------ vgasrc/Kconfig | 7 +++ 7 files changed, 235 insertions(+), 30 deletions(-) create mode 100644 vgasrc/ramfb.c -- 2.9.3

2 5

[PATCH] bochs_display_setup: return error on failure
by Gerd Hoffmann 15 Jun '18

15 Jun '18

Signed-off-by: Gerd Hoffmann <kraxel(a)redhat.com> --- vgasrc/bochsdisplay.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/vgasrc/bochsdisplay.c b/vgasrc/bochsdisplay.c index e1f90f9678..6a75f3787e 100644 --- a/vgasrc/bochsdisplay.c +++ b/vgasrc/bochsdisplay.c @@ -38,7 +38,7 @@ bochs_display_setup(void) dprintf(1, "bochs-display: id is 0x%x, %s\n", id , id == VBE_DISPI_ID5 ? "good" : "FAIL"); if (id != VBE_DISPI_ID5) - return 0; + return -1; dprintf(1, "bochs-display: using %dx%d, %d bpp (%d stride)\n" , FRAMEBUFFER_WIDTH, FRAMEBUFFER_HEIGHT -- 2.9.3

1 0

Re: [SeaBIOS] [PATCH 3/3] qemu: add qemu ramfb support
by Kevin O'Connor 14 Jun '18

14 Jun '18

On Wed, Jun 13, 2018 at 10:51:57AM +0200, Gerd Hoffmann wrote: > Add support for qemu ramfb. This is a simple boot framebuffer device, > with normal ram being used to back the framebuffer and fw_cfg being used > to configure the device. > > Use case (on x86): boot display for vgpu devices (which neither emulate > vga nor have a vgabios). [...] > --- /dev/null > +++ b/vgasrc/ramfb.c > @@ -0,0 +1,123 @@ > +#include "biosvar.h" // GET_BDA > +#include "output.h" // dprintf > +#include "string.h" // memset16_far > +#include "vgautil.h" // VBE_total_memory > +#include "std/pmm.h" // struct pmmheader > +#include "byteorder.h" > +#include "fw/paravirt.h" > + > +#define FRAMEBUFFER_WIDTH 1024 > +#define FRAMEBUFFER_HEIGHT 768 > +#define FRAMEBUFFER_BPP 4 > +#define FRAMEBUFFER_STRIDE (FRAMEBUFFER_BPP * FRAMEBUFFER_WIDTH) > +#define FRAMEBUFFER_SIZE (FRAMEBUFFER_STRIDE * FRAMEBUFFER_HEIGHT) > + > +struct QemuRAMFBCfg { > + u64 addr; > + u32 fourcc; > + u32 flags; > + u32 width; > + u32 height; > + u32 stride; > +}; > + > +#define fourcc_code(a, b, c, d) ((u32)(a) | ((u32)(b) << 8) | \ > + ((u32)(c) << 16) | ((u32)(d) << 24)) > + > +#define DRM_FORMAT_RGB565 fourcc_code('R', 'G', '1', '6') /* [15:0] R:G:B 5:6:5 little endian */ > +#define DRM_FORMAT_RGB888 fourcc_code('R', 'G', '2', '4') /* [23:0] R:G:B little endian */ > +#define DRM_FORMAT_XRGB8888 fourcc_code('X', 'R', '2', '4') /* [31:0] x:R:G:B 8:8:8:8 little endian */ > + > +static u32 > +allocate_framebuffer(void) > +{ > + u32 pmmscan; > + for (pmmscan=0; pmmscan < BUILD_BIOS_SIZE; pmmscan+=16) { > + struct pmmheader *pmm = (void*)pmmscan; > + if (GET_FARVAR(SEG_BIOS, pmm->signature) != PMM_SIGNATURE) > + continue; > + if (checksum_far(SEG_BIOS, pmm, GET_FARVAR(SEG_BIOS, pmm->length))) > + continue; > + struct segoff_s entry = GET_FARVAR(SEG_BIOS, pmm->entry); > + dprintf(1, "ramfb: alloc framebuffer via pmm call to %04x:%04x\n" > + , entry.seg, entry.offset); > + u16 res1, res2; > + asm volatile( > + "pushl %0\n" > + "pushw $(8|2)\n" // Permanent high memory request > + "pushl $0xffffffff\n" // Anonymous handle > + "pushl $" __stringify(FRAMEBUFFER_SIZE / 16) "\n" > + "pushw $0x00\n" // PMM allocation request > + "lcallw *12(%%esp)\n" > + "addl $16, %%esp\n" > + "cli\n" > + "cld\n" > + : "+r" (entry.segoff), "=a" (res1), "=d" (res2) : : "cc", "memory"); > + u32 res = res1 | (res2 << 16); > + if (!res || res == PMM_FUNCTION_NOT_SUPPORTED) > + return 0; > + dprintf(1, "ramfb: framebuffer allocated at %x\n", res); > + return res; > + } > + return 0; > +} It would be preferable to re-factor allocate_extra_stack() so there is just one pmm allocation function. > +int > +ramfb_setup(void) > +{ > + dprintf(1, "ramfb: init\n"); > + > + if (GET_GLOBAL(HaveRunInit)) > + return 0; > + > + u32 count; > + qemu_cfg_read_entry(&count, QEMU_CFG_FILE_DIR, sizeof(count)); > + count = be32_to_cpu(count); > + u32 select, e, fb; > + for (select = 0, e = 0; e < count; e++) { > + struct QemuCfgFile qfile; > + qemu_cfg_read(&qfile, sizeof(qfile)); > + if (memcmp_far(GET_SEG(SS), qfile.name, > + GET_SEG(CS), "etc/ramfb", 10) == 0) > + select = be16_to_cpu(qfile.select); > + } Could this be moved into a new qemu_cfg_scan_file() function in paravirt.c, and thus avoid patch 2? > + if (select == 0) { > + dprintf(1, "ramfb: fw_cfg (etc/ramfb) file not found\n"); > + return -1; > + } > + > + dprintf(1, "ramfb: fw_cfg (etc/ramfb) file at slot 0x%x\n", select); > + fb = allocate_framebuffer(); > + if (!fb) { > + dprintf(1, "ramfb: allocating framebuffer failed\n"); > + return -1; > + } > + > + u64 addr = fb; > + u8 bpp = FRAMEBUFFER_BPP * 8; > + u32 xlines = FRAMEBUFFER_WIDTH; > + u32 ylines = FRAMEBUFFER_HEIGHT; > + u32 linelength = FRAMEBUFFER_STRIDE; > + dprintf(1, "Found FB @ %llx %dx%d with %d bpp (%d stride)\n" > + , addr, xlines, ylines, bpp, linelength); > + > + if (!addr || addr > 0xffffffff > + || (bpp != 15 && bpp != 16 && bpp != 24 && bpp != 32)) { > + dprintf(1, "Unable to use FB\n"); > + return -1; > + } > + > + cbvga_setup_modes(addr, bpp, xlines, ylines, linelength); > + > + struct QemuRAMFBCfg cfg = { > + .addr = cpu_to_be64(fb), > + .fourcc = cpu_to_be32(DRM_FORMAT_XRGB8888), > + .flags = cpu_to_be32(0), > + .width = cpu_to_be32(FRAMEBUFFER_WIDTH), > + .height = cpu_to_be32(FRAMEBUFFER_HEIGHT), > + .stride = cpu_to_be32(FRAMEBUFFER_STRIDE), > + }; > + qemu_cfg_write_entry(&cfg, select, sizeof(cfg)); > + > + return 0; > +} > diff --git a/vgasrc/Kconfig b/vgasrc/Kconfig > index 4443c0b37a..1933b0e23f 100644 > --- a/vgasrc/Kconfig > +++ b/vgasrc/Kconfig > @@ -70,6 +70,13 @@ menu "VGA ROM" > v3.0+. The vgabios works with the qemu stdvga too (use > "qemu -device VGA,romfile=/path/to/vgabios.bin")". > > + config VGA_RAMFB > + depends on QEMU > + bool "qemu ram framebuffer (experimental)" > + select VGA_EMULATE_TEXT > + help > + qemu ram framebuffer (experimental) I see it is marked as experimental - is this a proof of concept patch or is this feature ready for a merge into qemu and seabios? Thanks, -Kevin

2 1

[PATCH 1/3] config: reserve more high memory (for ramfb)
by Gerd Hoffmann 14 Jun '18

14 Jun '18

qemu ramfb allows to place a boot framebuffer in normal ram. The ramfb vgabios needs a bigger chunk of ram for that, so increase the amout of reserved memory. Obvious drawback is we waste the memory in case ramfb isn't used. Better ideas are welcome. Signed-off-by: Gerd Hoffmann <kraxel(a)redhat.com> --- src/config.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/config.h b/src/config.h index 93c8dbc2d5..5912c0dd29 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 (4*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.9.3

2 3

KVM Forum 2018: Call For Participation
by Paolo Bonzini 12 Jun '18

12 Jun '18

================================================================ KVM Forum 2018: Call For Participation October 24-26, 2018 - Edinburgh International Conference Centre - Edinburgh, UK (All submissions must be received before midnight June 14, 2018) ================================================================= KVM Forum is an annual event that presents a rare opportunity for developers and users to meet, discuss the state of Linux virtualization technology, and plan for the challenges ahead. We invite you to lead part of the discussion by submitting a speaking proposal for KVM Forum 2018. At this highly technical conference, developers driving innovation in the KVM virtualization stack (Linux, KVM, QEMU, libvirt) can meet users who depend on KVM as part of their offerings, or to power their data centers and clouds. KVM Forum will include sessions on the state of the KVM virtualization stack, planning for the future, and many opportunities for attendees to collaborate. After more than ten years of development in the Linux kernel, KVM continues to be a critical part of the FOSS cloud infrastructure. This year, KVM Forum is joining Open Source Summit in Edinburgh, UK. Selected talks from KVM Forum will be presented on Wednesday October 24 to the full audience of the Open Source Summit. Also, attendees of KVM Forum will have access to all of the talks from Open Source Summit on Wednesday. https://events.linuxfoundation.org/events/kvm-forum-2018/program/cfp/ Suggested topics: * Scaling, latency optimizations, performance tuning, real-time guests * Hardening and security * New features * Testing KVM and the Linux kernel: * Nested virtualization * Resource management (CPU, I/O, memory) and scheduling * VFIO: IOMMU, SR-IOV, virtual GPU, etc. * Networking: Open vSwitch, XDP, etc. * virtio and vhost * Architecture ports and new processor features QEMU: * Management interfaces: QOM and QMP * New devices, new boards, new architectures * Graphics, desktop virtualization and virtual GPU * New storage features * High availability, live migration and fault tolerance * Emulation and TCG * Firmware: ACPI, UEFI, coreboot, U-Boot, etc. Management and infrastructure * Managing KVM: Libvirt, OpenStack, oVirt, etc. * Storage: Ceph, Gluster, SPDK, etc.r * Network Function Virtualization: DPDK, OPNFV, OVN, etc. * Provisioning =============== SUBMITTING YOUR PROPOSAL =============== Abstracts due: June 14, 2018 Please submit a short abstract (~150 words) describing your presentation proposal. Slots vary in length up to 45 minutes. Also include the proposal type -- one of: - technical talk - end-user talk Submit your proposal here:http://events.linuxfoundation.org/cfp Please only use the categories "presentation" and "panel discussion" You will receive a notification whether or not your presentation proposal was accepted by August 10, 2018. Speakers will receive a complimentary pass for the event. In the instance that case your submission has multiple presenters, only the primary speaker for a proposal will receive a complimentary event pass. For panel discussions, all panelists will receive a complimentary event pass. TECHNICAL TALKS A good technical talk should not just report on what has happened over the last year; it should present a concrete problem and how it impacts the user and/or developer community. Whenever applicable, focus on work that needs to be done, difficulties that haven't yet been solved, and on decisions that other developers should be aware of. Summarizing recent developments is okay but it should not be more than a small portion of the overall talk. END-USER TALKS One of the big challenges as developers is to know what, where and how people actually use our software. We will reserve a few slots for end users talking about their deployment challenges and achievements. If you are using KVM in production you are encouraged submit a speaking proposal. Simply mark it as an end-user talk. As an end user, this is a unique opportunity to get your input to developers. HANDS-ON / BOF SESSIONS We will reserve some time for people to get together and discuss strategic decisions as well as other topics that are best solved within smaller groups. These sessions will be announced during the event. If you are interested in organizing such a session, please add it to the list at http://www.linux-kvm.org/page/KVM_Forum_2018_BOF Let people you think who might be interested know about your BOF, and encourage them to add their names to the wiki page as well. Please try to add your ideas to the list before KVM Forum starts. PANEL DISCUSSIONS If you are proposing a panel discussion, please make sure that you list all of your potential panelists in your the abstract. We will request full biographies if a panel is acceped. =============== HOTEL / TRAVEL =============== This year's event will take place at the Edinburgh International Conference Centre. For information about discounted hotel room rate for conference attendees at the nearby Sheraton Grand Hotel & Spa, Edinburgh, please visit https://events.linuxfoundation.org/events/kvm-forum-2018/attend/venue-trave… =============== IMPORTANT DATES =============== Submission deadline: June 14, 2018 Notification: August 10, 2018 Schedule announced: August 16, 2018 Event dates: October 24-26, 2018 Thank you for your interest in KVM. We're looking forward to your submissions and seeing you at the KVM Forum 2018 in October! -your KVM Forum 2018 Program Committee Please contact us with any questions or comments at kvm-forum-2018-pc(a)redhat.com

2 1

Re: [SeaBIOS] 1TB Guest changes to receive phys bits >=40
by Gerd Hoffmann 12 Jun '18

12 Jun '18

Hi, > The change [2] itself is rather old, so I wondered if I'm missing that this > was implemented in a totally different way. Do I have to switch/set options > these days instead of using that patch? It should just work. qemu passes ram regions to the firmware using fw_cfg (etc/e820) these days, and both seabios and ovmf support this for years already. > So the question become why the change is not upstream yet? > Was it maybe discussed in the past and Nack'ed for some reason? Exactly. RHEL/CentOS 6 implemented the extra cmos byte, but this was not accepted upstream in favor of the more flexible e820 solution. RHEL/CentOS 7 supports both etc/e820 (upstream) and cmos (el6), but the later is only there for backward compatibility reasons. cheers, Gerd

2 1

Re: [SeaBIOS] 1TB Guest changes to receive phys bits >=40
by Paolo Bonzini 11 Jun '18

11 Jun '18

On 11/06/2018 15:21, Christian Ehrhardt wrote: > Hi, > I was asked about x86 Guests of >1TB in size. And while some discussions > where around qemu/libvirt and host-phys-bits [1] I realized that in > Seabios I need exactly what is already in CentOS/RHEL [2] to get the > phys-bits passed on. > > The change [2] itself is rather old, so I wondered if I'm missing that > this was implemented in a totally different way. Do I have to switch/set > options these days instead of using that patch? That patch is not needed anymore. It is only there to support old machine types. In newer versions of QEMU, QEMU builds the e820 memory map for SeaBIOS, and that is enough to support >=1TB guests nicely. Paolo > But I saw that it is still applied even to rather recent versions. > > So the question become why the change is not upstream yet? > Was it maybe discussed in the past and Nack'ed for some reason? > I didn't find the discussion if that is the case and would appreciate > the pointer. > > We are closing in to make 1TB more common rather quickly, so I wonder if > really nothing would speak against it - would it be reasonable to > consider committing that upstream to Seabios these days? > > [1]: https://bugs.launchpad.net/ubuntu/+source/qemu/+bug/1769053 > [2]: https://git.centos.org/blob/rpms!seabios.git/14f0fd75785bc5f1468fa84fbd3a16… > > P.S. Subscribing people acking the original patch as they might have old > context to provide on this. > > -- > Christian Ehrhardt > Software Engineer, Ubuntu Server > Canonical Ltd

2 1

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

SeaBIOS