SeaBIOS January 2013

seabios@seabios.org

27 participants
47 discussions

Next release
by Kevin O'Connor 09 Jan '13

09 Jan '13

It's been a few months since the last SeaBIOS release. I'd like to start preparing for the next release. If you know of any defects or critical features that should go into the next release, please let me know. I'd like to target January 18th for the next release. -Kevin

4 4

Re: [SeaBIOS] [RFC PATCH v4 26/30] Implement qmp and hmp commands for notification lists
by Eric Blake 09 Jan '13

09 Jan '13

On 12/18/2012 05:41 AM, Vasilis Liaskovitis wrote: > Guest can respond to ACPI hotplug events e.g. with _EJ or _OST method. > This patch implements a tail queue to store guest notifications for memory > hot-add and hot-remove requests. > > Guest responses for memory hotplug command on a per-dimm basis can be detected > with the new hmp command "info memory-hotplug" or the new qmp command > "query-memory-hotplug" > > Examples: > > (qemu) device_add dimm,id=ram0 > (qemu) info memory-hotplug > dimm: ram0 hot-add success > or > dimm: ram0 hot-add failure > > +++ b/qapi-schema.json > @@ -2940,6 +2940,32 @@ > { 'command': 'query-dimm-info', 'returns': ['DimmInfo'] } > > ## > +# @MemHpInfo: > +# > +# Information about status of a memory hotplug command > +# > +# @dimm: the Dimm associated with the result Didn't document @request. > +# > +# @result: the result of the hotplug command > +# > +# Since: 1.4 > +# > +## > +{ 'type': 'MemHpInfo', > + 'data': {'dimm': 'str', 'request': 'str', 'result': 'str'} } Instead of open-coding 'request' and 'result' as an arbitrary string, it would be nicer to have them be an enum type with a finite subset of expected values. > + > +## > +# @query-memory-hotplug: > +# > +# Returns a list of information about pending hotplug commands > +# > +# Returns: a list of @MemhpInfo s/MemhpInfo/MemHpInfo/ > +# > +# Since: 1.4 > +## > +{ 'command': 'query-memory-hotplug', 'returns': ['MemHpInfo'] } > + > +## > # @QKeyCode: > # -- Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org

1 0

Re: [SeaBIOS] [Qemu-devel] [RFC PATCH v4 06/30] qapi: make visit_type_size fallback to type_int
by Andreas Färber 09 Jan '13

09 Jan '13

Am 18.12.2012 13:41, schrieb Vasilis Liaskovitis: > Currently visit_type_size checks if the visitor's type_size function pointer is > NULL. If not, it calls it, otherwise it calls v->type_uint64(). But neither of > these pointers are ever set. Fallback to calling v->type_int() in this third > (default) case. > > Signed-off-by: Vasilis Liaskovitis <vasilis.liaskovitis(a)profitbricks.com> Is this patch still needed? I thought size -> int fallback was fixed differently for the deallocation visitor... Anyway, someone (Anthony?) recently suggested to drop the size visitor completely in favor of string type (cf. frequency visitor discussion). Regards, Andreas > --- > qapi/qapi-visit-core.c | 11 ++++++++++- > 1 files changed, 10 insertions(+), 1 deletions(-) > > diff --git a/qapi/qapi-visit-core.c b/qapi/qapi-visit-core.c > index 7a82b63..497e693 100644 > --- a/qapi/qapi-visit-core.c > +++ b/qapi/qapi-visit-core.c > @@ -236,8 +236,17 @@ void visit_type_int64(Visitor *v, int64_t *obj, const char *name, Error **errp) > > void visit_type_size(Visitor *v, uint64_t *obj, const char *name, Error **errp) > { > + int64_t value; > if (!error_is_set(errp)) { > - (v->type_size ? v->type_size : v->type_uint64)(v, obj, name, errp); > + if (v->type_size) { > + v->type_size(v, obj, name, errp); > + } else if (v->type_uint64) { > + v->type_uint64(v, obj, name, errp); > + } else { > + value = *obj; > + v->type_int(v, &value, name, errp); > + *obj = value; > + } > } > } > -- SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg

1 0

vga bios woes
by Alex Williamson 04 Jan '13

04 Jan '13

Hi, I was playing a bit with vfio-based PCI device assignment of VGA in qemu and I seem to be hitting a wall just trying to jump into the VGA BIOS. I'm booting qemu with -vga none and assigning a radeon hd5450 via vfio-pci with some extra code to handle passing legacy accesses through to the host. Legacy access hardly seems to matter though as the experiment quickly dies when the vcpu starts executing zero'd memory. gdb shows me something like this: 0x000f257c <__callrom+72>: 66 c7 44 24 16 ff ff movw $0xffff,0x16(%esp) 0x000f2583 <__callrom+79>: 66 c7 44 24 1a ff ff movw $0xffff,0x1a(%esp) 0x000f258a <__callrom+86>: 66 c7 44 24 08 00 f0 movw $0xf000,0x8(%esp) 0x000f2591 <__callrom+93>: b8 80 d1 0f 00 mov $0xfd180,%eax 0x000f2596 <__callrom+98>: 66 89 44 24 0a mov %ax,0xa(%esp) 0x000f259b <__callrom+103>: c1 e5 10 shl $0x10,%ebp 0x000f259e <__callrom+106>: 0f b7 d7 movzwl %di,%edx 0x000f25a1 <__callrom+109>: 09 ea or %ebp,%edx 0x000f25a3 <__callrom+111>: 89 54 24 26 mov %edx,0x26(%esp) 0x000f25a7 <__callrom+115>: 89 e0 mov %esp,%eax 0x000f25a9 <__callrom+117>: 3d 00 70 00 00 cmp $0x7000,%eax 0x000f25ae <__callrom+122>: 76 0a jbe 0xf25ba <__callrom+134> 0x000f25ba <__callrom+134>: 89 f0 mov %esi,%eax 0x000f25bc <__callrom+136>: bb 58 68 00 00 mov $0x6858,%ebx 0x000f25c1 <__callrom+141>: e8 31 98 00 00 call 0xfbdf7 0x000fbdf7: ba 01 be 00 00 mov $0xbe01,%edx 0x000fbdfc: e9 0e ff ff ff jmp 0xfbd0f 0x000fbd0f: 89 c1 mov %eax,%ecx 0x000fbd11: b8 30 00 00 00 mov $0x30,%eax 0x000fbd16: 8e d8 mov %eax,%ds 0x000fbd18: 8e c0 mov %eax,%es 0x000fbd1a: 8e d0 mov %eax,%ss 0x000fbd1c: 8e e0 mov %eax,%fs 0x000fbd1e: 8e e8 mov %eax,%gs 0x000fbd20: 66 ea 26 bd 28 00 ljmpw $0x28,$0xbd26 0x0000bd26: 00 00 add %al,(%eax) (qemu) xp /16x 0x0000bd26 000000000000bd26: 0x00000000 0x00000000 0x00000000 0x00000000 000000000000bd36: 0x00000000 0x00000000 0x00000000 0x00000000 000000000000bd46: 0x00000000 0x00000000 0x00000000 0x00000000 000000000000bd56: 0x00000000 0x00000000 0x00000000 0x00000000 (qemu) xp /16x 0x000c0000 00000000000c0000: 0xe975aa55 0x00000221 0x00000000 0x00000000 00000000000c0010: 0x00000000 0x00000000 0x000001d4 0x42490000 00000000000c0020: 0x0000254d 0x00000000 0x00000000 0x04000000 00000000000c0030: 0x31363720 0x35353932 0x00003032 0x00000000 Trying to follow the code into __callrom(), I'm really confused how the option rom init vector is actually used since callrom() passes the option rom header offset to the init vector rather than anything actually resembling the value of the init vector. I really don't know x86 though, so maybe I'm missing something. The option rom is loaded as a PCI expansion rom from the device, it appears to be non-PnP. The seabios log shows this: Scan for VGA option rom Attempting to init PCI bdf 00:02.0 (vd 1002:68f9) Attempting to map option rom on dev 00:02.0 Option rom sizing returned febe0000 fffe0000 Inspecting possible rom at 0xfebe0000 (vd=1002:68f9 bdf=00:02.0) Copying option rom (size 59904) from 0xfebe0000 to 0x000c0000 handle_08 Checking rom 0x000c0000 (sig aa55 size 117) Running option rom at c000:0003 <here we go into the weeds, I'll continue to see periodic handle_08 if I let it run> Appreciate any hints to make this work. Thanks, Alex

3 7

Re: [SeaBIOS] vga bios woes
by Alex Williamson 04 Jan '13

04 Jan '13

On Thu, 2013-01-03 at 18:43 -0700, Daniel Verkamp wrote: > On Thu, Jan 3, 2013 at 2:31 PM, Alex Williamson > <alex.williamson(a)redhat.com> wrote: > > Hi, > > > > I was playing a bit with vfio-based PCI device assignment of VGA in qemu > > and I seem to be hitting a wall just trying to jump into the VGA BIOS. > > I'm booting qemu with -vga none and assigning a radeon hd5450 via > > vfio-pci with some extra code to handle passing legacy accesses through > > to the host. Legacy access hardly seems to matter though as the > > experiment quickly dies when the vcpu starts executing zero'd memory. > > gdb shows me something like this: > > > > 0x000f257c <__callrom+72>: 66 c7 44 24 16 ff ff movw $0xffff,0x16(%esp) > > 0x000f2583 <__callrom+79>: 66 c7 44 24 1a ff ff movw $0xffff,0x1a(%esp) > > 0x000f258a <__callrom+86>: 66 c7 44 24 08 00 f0 movw $0xf000,0x8(%esp) > > 0x000f2591 <__callrom+93>: b8 80 d1 0f 00 mov $0xfd180,%eax > > 0x000f2596 <__callrom+98>: 66 89 44 24 0a mov %ax,0xa(%esp) > > 0x000f259b <__callrom+103>: c1 e5 10 shl $0x10,%ebp > > 0x000f259e <__callrom+106>: 0f b7 d7 movzwl %di,%edx > > 0x000f25a1 <__callrom+109>: 09 ea or %ebp,%edx > > 0x000f25a3 <__callrom+111>: 89 54 24 26 mov %edx,0x26(%esp) > > 0x000f25a7 <__callrom+115>: 89 e0 mov %esp,%eax > > 0x000f25a9 <__callrom+117>: 3d 00 70 00 00 cmp $0x7000,%eax > > 0x000f25ae <__callrom+122>: 76 0a jbe 0xf25ba <__callrom+134> > > 0x000f25ba <__callrom+134>: 89 f0 mov %esi,%eax > > 0x000f25bc <__callrom+136>: bb 58 68 00 00 mov $0x6858,%ebx > > 0x000f25c1 <__callrom+141>: e8 31 98 00 00 call 0xfbdf7 > > 0x000fbdf7: ba 01 be 00 00 mov $0xbe01,%edx > > 0x000fbdfc: e9 0e ff ff ff jmp 0xfbd0f > > 0x000fbd0f: 89 c1 mov %eax,%ecx > > 0x000fbd11: b8 30 00 00 00 mov $0x30,%eax > > 0x000fbd16: 8e d8 mov %eax,%ds > > 0x000fbd18: 8e c0 mov %eax,%es > > 0x000fbd1a: 8e d0 mov %eax,%ss > > 0x000fbd1c: 8e e0 mov %eax,%fs > > 0x000fbd1e: 8e e8 mov %eax,%gs > > 0x000fbd20: 66 ea 26 bd 28 00 ljmpw $0x28,$0xbd26 > > 0x0000bd26: 00 00 add %al,(%eax) > > I think GDB is probably getting lost at the far jump (ljmpw). To my > knowledge, GDB does not understand the x86 segmented real-mode memory > model. > > The trace above is __callrom() -> farcall16big() -> call16big() -> > __call16big() -> transition16big in romlayout.S, which contains the > ljmpw in question. > > > Trying to follow the code into __callrom(), I'm really confused how the > > option rom init vector is actually used since callrom() passes the > > option rom header offset to the init vector rather than anything > > actually resembling the value of the init vector. I really don't know > > x86 though, so maybe I'm missing something. > > The far address of the ROM initialization vector (seg:offset) is being > loaded into br.code, which will get used later on in the farcall > helper functions noted above. The offset is set to > OPTION_ROM_INITVECTOR by callrom(), which is 3; this is relative to > the segment of the ROM header (hence the FLATPTR_TO_SEG in __callrom). > The ROM header should have a jump at that location to the real > initialization code. > > I don't have any real tips on how to make this work - hopefully > someone else will know the magic incantation to clue in GDB to the new > code segment. > > This blog post also looks relevant: > http://crustynation.net/wiki/doku.php?id=blog:gdb_real_mode Awesome! That gdbinit is magic. Thanks for the pointer, Alex

1 0

Access disk in read-only mode
by Fred . 03 Jan '13

03 Jan '13

Before you could boot a OS from a LiveCD and have it secure because CD is read-only and non-writable. Now less and less machines comes with optical drives. It would be nice with a setting to boot disks or USB as read-only so the OS can not write to the disk.

1 0

Boot sector protection
by Fred . 03 Jan '13

03 Jan '13

Add option to enable boot sector protection to prevent writes to the boot sector and MBR of a hard disk. In order to prevent boot sector viruses and corruption of partition tables.

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

SeaBIOS January 2013