SeaBIOS April 2012

seabios@seabios.org

27 participants
63 discussions

[RFC PATCH 1/9] Add SSDT memory device support
by Vasilis Liaskovitis 19 Apr '12

19 Apr '12

Define SSDT hotplug-able memory devices in _SB namespace. The dynamically generated SSDT includes per memory device hotplug methods. These methods just call methods defined in the DSDT. Also dynamically generate a MTFY method and a MEON array of the online/available memory devices. Add file src/ssdt-mem.dsl with directions for generating the per-memory device processor object AML code. The design is taken from SSDT cpu generation. Signed-off-by: Vasilis Liaskovitis <vasilis.liaskovitis(a)profitbricks.com> --- src/ssdt-mem.dsl | 66 ++++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 files changed, 66 insertions(+), 0 deletions(-) create mode 100644 src/ssdt-mem.dsl diff --git a/src/ssdt-mem.dsl b/src/ssdt-mem.dsl new file mode 100644 index 0000000..9586643 --- /dev/null +++ b/src/ssdt-mem.dsl @@ -0,0 +1,66 @@ +/* This file is the basis for the ssdt_mem[] variable in src/acpi.c. + * It is similar in design to the ssdt_proc variable. + * It defines the contents of the per-cpu Processor() object. At + * runtime, a dynamically generated SSDT will contain one copy of this + * AML snippet for every possible memory device in the system. The + * objects will * be placed in the \_SB_ namespace. + * + * To generate a new ssdt_memc[], run the commands: + * cpp -P src/ssdt-mem.dsl > out/ssdt-mem.dsl.i + * iasl -ta -p out/ssdt-mem out/ssdt-mem.dsl.i + * tail -c +37 < out/ssdt-mem.aml | hexdump -e '" " 8/1 "0x%02x," "\n"' + * and then cut-and-paste the output into the src/acpi.c ssdt_mem[] + * array. + * + * In addition to the aml code generated from this file, the + * src/acpi.c file creates a MEMNTFY method with an entry for each memdevice: + * Method(MTFY, 2) { + * If (LEqual(Arg0, 0x00)) { Notify(MP00, Arg1) } + * If (LEqual(Arg0, 0x01)) { Notify(MP01, Arg1) } + * ... + * } + * and a MEON array with the list of active and inactive memory devices: + * Name(MEON, Package() { One, One, ..., Zero, Zero, ... }) + */ +DefinitionBlock ("ssdt-mem.aml", "SSDT", 0x02, "BXPC", "CSSDT", 0x1) +/* v------------------ DO NOT EDIT ------------------v */ +{ + Device(MPAA) { + Name(ID, 0xAA) +/* ^------------------ DO NOT EDIT ------------------^ + * + * The src/acpi.c code requires the above layout so that it can update + * MPAA and 0xAA with the appropriate MEMDEVICE id (see + * SD_OFFSET_MEMHEX/MEMID1/MEMID2). Don't change the above without + * also updating the C code. + */ + Name(_HID, EISAID("PNP0C80")) + Name(_PXM, 0xAA) + + External(CMST, MethodObj) + External(MPEJ, MethodObj) + + Name(_CRS, ResourceTemplate() { + QwordMemory( + ResourceConsumer, + , + MinFixed, + MaxFixed, + Cacheable, + ReadWrite, + 0x0, + 0xDEADBEEF, + 0xE6ADBEEE, + 0x00000000, + 0x08000000, + ) + }) + Method (_STA, 0) { + Return(CMST(ID)) + } + Method (_EJ0, 1, NotSerialized) { + MPEJ(ID, Arg0) + } + } +} + -- 1.7.9

1 0

[RFC PATCH 0/9] ACPI memory hotplug
by Vasilis Liaskovitis 19 Apr '12

19 Apr '12

This is a prototype for ACPI memory hotplug on x86_64 target. Based on some earlier work and comments from Gleb. Memslot devices are modeled with a new qemu command line "-memslot id=name,start=start_addr,size=sz,node=pxm" user is responsible for defining memslots with meaningful start/size values, e.g. not defining a memory slot over a PCI-hole. Alternatively, the start size could also be handled/assigned automatically from the specific emulated hardware (for hw/pc.c PCI hole is currently [below_4g_mem_size, 4G), so hotplugged memory should start from max(4G, above_4g_mem_size). Node is defining numa proximity for this memslot. When not defined it defaults to zero. e.g. "-memslot id=hot1,start=4294967296,size=536870912,node=0" will define a 512M memory slot starting at physical address 4G, belonging to numa node 0. Memory slots are added or removed with a new hmp command "memslot": Hot-add syntax: "memslot id add" Hot-remove syntax: "memslot id delete" - All memslots are initially unpopulated. Memslots are currently modeling only hotplug-able memory slots i.e. initial system memory is not modeled with memslots. The concept could be generalized to include all memory though, or it could more closely follow kvm-memory slots. - Memslots are abstracted as qdevices attached to the main system bus. However, memory hotplugging has its own side channel ignoring main_system_bus's hotplug incapability. A cleaner integration would be needed. What's the preferred way of modeling memory devices in qom? Would it be better to attach memory devices as children-links of an acpi-capable device (in the pc case acpi_piix4) instead of the system bus? - Refcounting memory slots has been discussed (but is not included in this series yet). Depopulating a memory region happens on a guestOS _EJ callback, which means the guestOS will not be using the region anymore. However, guest addresses from the depopulated region need to also be unmapped from the qemu address space using cpu_physical_memory_unmap(). Does memory_region_del_subregion() or some other memory API call guarantee that a memoryregion has been unmapped from qemu's address space? - What is the expected behaviour of hotplugged memory after a reboot? Is it supposed to be persistent after reboots? The last 2 patches in the series try to make hotplugged memslots persistent after reboot by creating and consulting e820 map entries. A better solution is needed for hot-remove after a reboot, because e820 entries can be merged. series is based on uq/master for qemu-kvm, and master for seabios. Can be found also at: Vasilis Liaskovitis (9): Seabios: Add SSDT memory device support Seabios, acpi: Implement acpi-dsdt functions for memory hotplug. Seabios, acpi: generate hotplug memory devices. Implement memslot device abstraction acpi_piix4: Implement memory device hotplug registers and handlers. pc: pass paravirt info for hotplug memory slots to BIOS Implement memslot command-line option and memslot hmp monitor command pc: adjust e820 map on hot-add and hot-remove Seabios, acpi: enable memory devices if e820 entry is present Makefile.objs | 2 +- hmp-commands.hx | 15 ++++ hw/acpi_piix4.c | 103 +++++++++++++++++++++++++++- hw/memslot.c | 201 +++++++++++++++++++++++++++++++++++++++++++++++++++++++ hw/memslot.h | 44 ++++++++++++ hw/pc.c | 87 ++++++++++++++++++++++-- hw/pc.h | 1 + monitor.c | 8 ++ monitor.h | 1 + qemu-config.c | 25 +++++++ qemu-options.hx | 8 ++ sysemu.h | 1 + vl.c | 44 ++++++++++++- 13 files changed, 528 insertions(+), 12 deletions(-) create mode 100644 hw/memslot.c create mode 100644 hw/memslot.h create mode 100644 src/ssdt-mem.dsl src/acpi-dsdt.dsl | 68 ++++++++++++++++++++++- src/acpi.c | 155 +++++++++++++++++++++++++++++++++++++++++++++++++++-- src/memmap.c | 15 +++++ src/ssdt-mem.dsl | 66 ++++++++++++++++++++++ 4 files changed, 298 insertions(+), 6 deletions(-) create mode 100644 src/ssdt-mem.dsl -- 1.7.9

1 0

Call for Proposals: Linux Plumbers Conference (Aug 2012)
by Amit Shah 19 Apr '12

19 Apr '12

Hello, The Call for Proposals for the Linux Plumbers Conf 2012 is out. We're looking for speakers to talk at the Virtualization microconference as well as the main conference. The deadline for proposal submissions is 1st May. This year's edition of LPC is co-located with LinuxCon NA and will be held at San Diego from the 29th to the 31st of August. More details are at: http://www.linuxplumbersconf.org/2012/2012-lpc-call-for-proposals/ Please note: to submit a proposal for the virt microconf, use the 'lpc2012-virt-' prefix in the Name field. LPC is oriented towards solving problems, and good proposal topics are those which are unresolved problems or proposals that need interaction with multiple subsystems. Please see the CFP page linked above for more details. Thanks, Amit

1 0

Re: [SeaBIOS] [Qemu-devel] [PATCH 0/3] switch to seavgabios
by Gerd Hoffmann 19 Apr '12

19 Apr '12

Hi, [ adding seabios list to Cc:, topic is the missing vesa 2.0 protected mode interface in seavgabios ] >> Pointer? >> I'd like to have a test case which breaks with the new vgabios. > > We talked with malc briefly on irc yesterday, and this is what > he gave me: > > http://cvs.savannah.gnu.org/viewvc/vgabios/vbe.c?root=vgabios&r1=1.47&r2=1.… > > this is not the test case but the missing support he's referring to. > > It appears the patch implements just 2 functions which both just does > int10, It isn't that simple. Just invoking int10 from protected mode isn't guaranteed to have the desired effect. It certainly wouldn't work for linux vesafb panning. It might work for dos extenders, they might have the idt entry for int10 and other bios interrupts setup accordingly to do a real-mode -> bios call -> protected mode transition to simplify porting dos code to the 32bit extender. But even for that use case it is IMHO pointless as the reason to have a 32bit interface is to avoid the expensive real mode switch in the first place ... The code has been changed later on, for good reasons, see http://git.qemu.org/?p=vgabios.git;a=commitdiff;h=72c270d8091fb0f09e8291cc0… > so should be easy to implement in seabios, seavgabios has no 32bit code at all at the moment. vesa pmi didn't seem to be important enougth to change it. seabios is a 16/32bit hybrid with some code being compiled twice for both modes; dunno how reusable the seabios infrastructure is. Unlike seabios seavgabios has no fixed load address, which makes things a bit more complicated when it comes to global variables I think. At least for the bochs interface this wouldn't be a showstopper though. Instead of using global variables to figure stuff like the active video mode we can just read the bits we need from the bochs device registers. Costs some extra vmexits of course, and we wouldn't have code sharing for 16+32bit paths. cheers, Gerd

3 4

Re: [SeaBIOS] [Qemu-devel] [PATCH 0/3] switch to seavgabios
by Gerhard Wiesinger 19 Apr '12

19 Apr '12

Negative also here: Don't see anything on screen on startup... From log, latest qemu-kvm git version: Running option rom at c180:3d4e Running option rom at c180:3da2 Running option rom at c180:3df6 Running option rom at c580:0003 qemu-system-x86_64: /root/download/qemu/git/qemu-kvm/exec.c:2641: register_subpage: Assertion `existing.mr->subpage || existing.mr == &io_mem_unassigned' failed. Startup is done with the following command: /root/download/qemu/git/qemu-kvm/x86_64-softmmu/qemu-system-x86_64 -drive file=1.img,media=disk,if=scsi,bus=0,unit=0 -drive file=2.img,media=disk,if=scsi,bus=0,unit=1 -drive file=3.img,media=disk,if=scsi,bus=0,unit=2 -boot order=cad,menu=on -m 2048 -k de -vga vmware -vnc :0 -bios /root/download/seabios/git/seabios/out/bios.bin -chardev stdio,id=seabios -device isa-debugcon,iobase=0x402,chardev=seabios -option-rom BIOS/V4.19/8xx_64.rom -device rtl8139,mac=00:02:44:92:87:6a,vlan=0,romfile= -net tap,ifname=tap0,script=no,downscript=no,vlan=0 Backtrace isn't valid. Old integrated BIOS is valid and works well. Ciao, Gerhard On 17.04.2012 12:11, Gerd Hoffmann wrote: > Hi, > > This patch series switches the vgabios binaries shipped by qemu from the > lgpl'ed vgabios to the seabios version. > > There should be no guest-visible changes (especially no regressions) in > theory. The only known (and intentional) exception is the vesa 2.0 > protected mode interface which is not implemented by the seavgabios. > There are no known issues with linux and windows guests. Testing with > other, more exotic guests is very welcome. > > Note #1: Just pull from git to test, I've zapped the big binary patches > so you can't 'git am' them. > > Note #2: This goes on top of the seabios-1.7.0 pull request just sent, > so pulling this will pull the seabios update too. > > please give it a spin, > Gerd > > The following changes since commit 6b034aa138716a515c88f7894940d5d0aff2f3ed: > > seabios: update to 1.7.0 (2012-04-17 10:51:41 +0200) > > are available in the git repository at: > git://git.kraxel.org/qemu seavgabios-1.7.0 > > Gerd Hoffmann (3): > Add seavgabios build rules to roms/Makefile > Update vgabios binaries > Switch isa vga to seavgabios too. > > hw/vga-isa.c | 2 +- > hw/vga_int.h | 1 - > pc-bios/vgabios-cirrus.bin | Bin 35840 -> 37888 bytes > pc-bios/vgabios-isavga.bin | Bin 0 -> 37888 bytes > pc-bios/vgabios-qxl.bin | Bin 40448 -> 37888 bytes > pc-bios/vgabios-stdvga.bin | Bin 40448 -> 37888 bytes > pc-bios/vgabios-vmware.bin | Bin 40448 -> 37888 bytes > roms/Makefile | 13 +++++++++++++ > roms/config.vga.cirrus | 3 +++ > roms/config.vga.isavga | 3 +++ > roms/config.vga.qxl | 6 ++++++ > roms/config.vga.stdvga | 3 +++ > roms/config.vga.vmware | 6 ++++++ > 13 files changed, 35 insertions(+), 2 deletions(-) > create mode 100644 pc-bios/vgabios-isavga.bin > create mode 100644 roms/config.vga.cirrus > create mode 100644 roms/config.vga.isavga > create mode 100644 roms/config.vga.qxl > create mode 100644 roms/config.vga.stdvga > create mode 100644 roms/config.vga.vmware >

2 1

[PATCH] vgabios: Improve Kconfig descriptions for the vga card types.
by Kevin O'Connor 17 Apr '12

17 Apr '12

Signed-off-by: Kevin O'Connor <kevin(a)koconnor.net> --- vgasrc/Kconfig | 17 +++++++++-------- 1 files changed, 9 insertions(+), 8 deletions(-) diff --git a/vgasrc/Kconfig b/vgasrc/Kconfig index c436aeb..6b22c39 100644 --- a/vgasrc/Kconfig +++ b/vgasrc/Kconfig @@ -12,13 +12,14 @@ menu "VGA ROM" config VGA_STANDARD_VGA depends on !COREBOOT - bool "Standard VGA" + bool "QEMU/Bochs Original IBM 256K VGA" help - Build basic VGA BIOS support for use on emulators. + Build basic VGA BIOS support (pre Super-VGA) for use + on emulators. config VGA_CIRRUS depends on !COREBOOT - bool "QEMU Cirrus CLGD 54xx VGA BIOS" + bool "QEMU/Bochs Cirrus SVGA" help Build support for Cirrus VGA emulation found on QEMU and Bochs emulators. This is for emulators; it is not @@ -26,18 +27,18 @@ menu "VGA ROM" config VGA_BOCHS depends on !COREBOOT - bool "Bochs DISPI interface VGA BIOS" + bool "QEMU/Bochs VBE SVGA" help - Build support for Bochs DISPI interface found on QEMU - and Bochs emulators. + Build support for Bochs DISPI interface (a custom VBE + protocol) found on QEMU and Bochs emulators. config VGA_GEODEGX2 - bool "GeodeGX2 interface VGA BIOS" + bool "GeodeGX2" help Build support for Geode GX2 vga. config VGA_GEODELX - bool "GeodeLX interface VGA BIOS" + bool "GeodeLX" help Build support for Geode LX vga. endchoice -- 1.7.6.5

3 3

[ANNOUNCE] SeaBIOS 1.7.0
by Kevin O'Connor 17 Apr '12

17 Apr '12

The 1.7.0 version of SeaBIOS has now been released. For more information on the release, please see: http://seabios.org/Releases New in this release: * Many enhancements to VGA BIOS code - it should now be feature complete with LGPL vgabios. * Support for virtio-scsi. * Improved USB drive (usb-msc) support. * Several USB controller bug fixes and improvements. * Runtime ACPI AML PCI hotplug construction. * Support for running on i386 and i486 CPUs. * Enhancements to PCI init when running on emulators. * Several bug fixes For information on obtaining SeaBIOS, please see: http://seabios.org/Download -Kevin

8 17

Re: [SeaBIOS] BEV and bootorder
by Gleb Natapov 15 Apr '12

15 Apr '12

On Sun, Apr 15, 2012 at 02:39:45PM +0200, Fred . wrote: > 2012/4/15 Gleb Natapov <gleb(a)redhat.com>: > > On Sun, Apr 15, 2012 at 02:24:05PM +0200, Fred . wrote: > >> Why would anyone want to define some devices as unbootable? > >> > > Because he does not want to boot from them. > > Then the partition should not be flagged as a boot partition, and it > won't be booted from. > Then it proceeds to try to boot from the next device. Adding flag to qemu is easier then modifying partitions. In reality all partitions are marked as boot partition during format. And there are other bootable devices besides HDs. > > > >> On Sun, Apr 15, 2012 at 8:57 AM, Gleb Natapov <gleb(a)redhat.com> wrote: > >> > On Sat, Apr 14, 2012 at 11:19:31PM -0400, Kevin O'Connor wrote: > >> >> On Thu, Apr 12, 2012 at 01:30:36PM -0600, Steve Goodrich wrote: > >> >> > I'm working towards a goal of having specific devices be bootable, and > >> >> > *only* those devices. For example, if my bootorder file specifies SATA > >> >> > drive 3, I do not want it to try SATA drives 0, 1, and 2, nor any other HDD > >> >> > or floppy that it finds. > >> >> > > >> >> > My first question is: how do I do this? > >> >> > >> >> There is no current way to do this. I suppose one could code support > >> >> for a "stop boot" option to the boot order file - so that if it was > >> >> listed in the file the boot would stop after trying all options prior > >> >> to it. > >> >> > >> > I thought to add skipboot file. If device is in skipboot file it is not > >> > considered for booting from. > >> > > >> >> > If that can't be answered, can someone explain to me the relationship > >> >> > between the bootorder file and the BEV (Boot Execution Vector) configured in > >> >> > boot.c? > >> >> > >> >> All possible boot options (both BEV and BCV) are assembled in a sorted > >> >> list pointed to by boot.c:BootList. The bootorder file alters the > >> >> default sort order of that list. During the latter parts of the POST > >> >> phase, the BCVs are executed and only BEVs remain. The list of BEVs > >> >> is generated from the BootList. So, in a nutshell, the bootorder file > >> >> determines the order of the BEVs that SeaBIOS will attempt to boot > >> >> from. > >> >> > >> >> -Kevin > >> >> > >> >> _______________________________________________ > >> >> SeaBIOS mailing list > >> >> SeaBIOS(a)seabios.org > >> >> http://www.seabios.org/mailman/listinfo/seabios > >> > > >> > -- > >> > Gleb. > >> > > >> > _______________________________________________ > >> > SeaBIOS mailing list > >> > SeaBIOS(a)seabios.org > >> > http://www.seabios.org/mailman/listinfo/seabios > > > > -- > > Gleb. -- Gleb.

1 0

Re: [SeaBIOS] BEV and bootorder
by Gleb Natapov 15 Apr '12

15 Apr '12

On Sun, Apr 15, 2012 at 02:24:05PM +0200, Fred . wrote: > Why would anyone want to define some devices as unbootable? > Because he does not want to boot from them. > On Sun, Apr 15, 2012 at 8:57 AM, Gleb Natapov <gleb(a)redhat.com> wrote: > > On Sat, Apr 14, 2012 at 11:19:31PM -0400, Kevin O'Connor wrote: > >> On Thu, Apr 12, 2012 at 01:30:36PM -0600, Steve Goodrich wrote: > >> > I'm working towards a goal of having specific devices be bootable, and > >> > *only* those devices. For example, if my bootorder file specifies SATA > >> > drive 3, I do not want it to try SATA drives 0, 1, and 2, nor any other HDD > >> > or floppy that it finds. > >> > > >> > My first question is: how do I do this? > >> > >> There is no current way to do this. I suppose one could code support > >> for a "stop boot" option to the boot order file - so that if it was > >> listed in the file the boot would stop after trying all options prior > >> to it. > >> > > I thought to add skipboot file. If device is in skipboot file it is not > > considered for booting from. > > > >> > If that can't be answered, can someone explain to me the relationship > >> > between the bootorder file and the BEV (Boot Execution Vector) configured in > >> > boot.c? > >> > >> All possible boot options (both BEV and BCV) are assembled in a sorted > >> list pointed to by boot.c:BootList. The bootorder file alters the > >> default sort order of that list. During the latter parts of the POST > >> phase, the BCVs are executed and only BEVs remain. The list of BEVs > >> is generated from the BootList. So, in a nutshell, the bootorder file > >> determines the order of the BEVs that SeaBIOS will attempt to boot > >> from. > >> > >> -Kevin > >> > >> _______________________________________________ > >> SeaBIOS mailing list > >> SeaBIOS(a)seabios.org > >> http://www.seabios.org/mailman/listinfo/seabios > > > > -- > > Gleb. > > > > _______________________________________________ > > SeaBIOS mailing list > > SeaBIOS(a)seabios.org > > http://www.seabios.org/mailman/listinfo/seabios -- Gleb.

2 1

Re: [SeaBIOS] BEV and bootorder
by Kevin O'Connor 15 Apr '12

15 Apr '12

On Thu, Apr 12, 2012 at 01:30:36PM -0600, Steve Goodrich wrote: > I'm working towards a goal of having specific devices be bootable, and > *only* those devices. For example, if my bootorder file specifies SATA > drive 3, I do not want it to try SATA drives 0, 1, and 2, nor any other HDD > or floppy that it finds. > > My first question is: how do I do this? There is no current way to do this. I suppose one could code support for a "stop boot" option to the boot order file - so that if it was listed in the file the boot would stop after trying all options prior to it. > If that can't be answered, can someone explain to me the relationship > between the bootorder file and the BEV (Boot Execution Vector) configured in > boot.c? All possible boot options (both BEV and BCV) are assembled in a sorted list pointed to by boot.c:BootList. The bootorder file alters the default sort order of that list. During the latter parts of the POST phase, the BCVs are executed and only BEVs remain. The list of BEVs is generated from the BootList. So, in a nutshell, the bootorder file determines the order of the BEVs that SeaBIOS will attempt to boot from. -Kevin

3 2

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

SeaBIOS April 2012