SeaBIOS April 2012

seabios@seabios.org

27 participants
63 discussions

Re: [SeaBIOS] [RFC PATCH 3/9] acpi: generate hotplug memory devices.
by Kevin O'Connor 24 Apr '12

24 Apr '12

On Thu, Apr 19, 2012 at 04:08:41PM +0200, Vasilis Liaskovitis wrote: > The memory device generation is guided by qemu paravirt info. Seabios > first uses the info to setup SRAT entries for the hotplug-able memory slots. > Afterwards, build_memssdt uses the created SRAT entries to generate > appropriate memory device objects. One memory device (and corresponding SRAT > entry) is generated for each hotplug-able qemu memslot. Currently no SSDT > memory device is created for initial system memory (the method can be > generalized to all memory though). > > Signed-off-by: Vasilis Liaskovitis <vasilis.liaskovitis(a)profitbricks.com> > --- > src/acpi.c | 151 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++-- > 1 files changed, 147 insertions(+), 4 deletions(-) > > diff --git a/src/acpi.c b/src/acpi.c > index 30888b9..5580099 100644 > --- a/src/acpi.c > +++ b/src/acpi.c > @@ -484,6 +484,131 @@ build_ssdt(void) > return ssdt; > } > > +static unsigned char ssdt_mem[] = { > + 0x5b,0x82,0x47,0x07,0x4d,0x50,0x41,0x41, This patch looks like it uses the SSDT generation mechanism that was present in SeaBIOS v1.6.3. Since then, however, the runtime AML code generation has been improved to be more dynamic. Any runtime generated AML code should be updated to use the newer mechanisms. -Kevin

2 1

Re: [SeaBIOS] [RFC PATCH 0/9] ACPI memory hotplug
by Gleb Natapov 24 Apr '12

24 Apr '12

On Mon, Apr 23, 2012 at 02:31:15PM +0200, Vasilis Liaskovitis wrote: > Hi, > > On Sun, Apr 22, 2012 at 05:20:59PM +0300, Gleb Natapov wrote: > > On Sun, Apr 22, 2012 at 05:13:27PM +0300, Avi Kivity wrote: > > > On 04/22/2012 05:09 PM, Gleb Natapov wrote: > > > > On Sun, Apr 22, 2012 at 05:06:43PM +0300, Avi Kivity wrote: > > > > > On 04/22/2012 04:56 PM, Gleb Natapov wrote: > > > > > > start. We will need it for migration anyway. > > > > > > > > > > > > > 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. > > > > > > OK, I hope final version will allow for memory < 4G to be hot-pluggable. > > > > > > > > > > Why is that important? > > > > > > > > > Because my feeling is that people that want to use this kind of feature > > > > what to start using it with VMs smaller than 4G. Of course not all > > > > memory have to be hot unpluggable. Making first 1M or event first 128M not > > > > unpluggable make perfect sense. > > > > > > Can't you achieve this with -m 1G, -device dimm,size=1G,populated=true > > > -device dimm,size=1G,populated=false? > > > > > From this: > > > > (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). > > > > I understand that hotpluggable memory can start from above 4G only. With > > the config above we will have memory hole from 1G to PCI memory hole. > > May be not a big problem, but I do not see technical reason for the constrain. > > > The 440fx spec mentions: "The address range from the top of main DRAM to 4 > Gbytes (top of physical memory space supported by the 440FX PCIset) is normally > mapped to PCI. The PMC forwards all accesses within this address range to PCI." > > What we probably want is that the initial memory map creation takes into account > all dimms specified (both populated/unpopulated) Yes. > So "-m 1G, -device dimm,size=1G,populated=true -device dimm,size=1G,populated=false" > would create a system map with top of memory and start of PCI-hole at 2G. > What -m 1G means on this command line? Isn't it redundant? May be we should make -m create non unplaggable, populated slot starting at address 0. Ten you config above will specify 3G memory with 2G populated (first of which is not removable) and 1G unpopulated. PCI hole starts above 3G. > This may require some shifting of physical address offsets around > 3.5GB-4GB - is this the minimum PCI hole allowed? Currently it is 1G in QEMU code. > > E.g. if we specify 4x1GB DIMMs (onlt the first initially populated) > -m 1G, -device dimm,size=1G,populated=true -device dimm,size=1G,populated=false > -device dimm,size=1G,populated=false -device dimm,size=1G,populated=false > > we create the following memory map: > dimm0: [0,1G) > dimm1: [1G, 2G) > dimm2: [2G, 3G) > dimm3: [4G, 5G) or dimm3 is split into [3G, 3.5G) and [4G, 4.5G) > > does either of these options sound reasonable? > We shouldn't split dimms IMO. Just unnecessary complication. Better make bigger PCI hole. -- Gleb.

2 1

Re: [SeaBIOS] [RFC PATCH 8/9] pc: adjust e820 map on hot-add and hot-remove
by Gleb Natapov 23 Apr '12

23 Apr '12

On Mon, Apr 23, 2012 at 01:27:40PM +0200, Vasilis Liaskovitis wrote: > On Sun, Apr 22, 2012 at 04:58:47PM +0300, Gleb Natapov wrote: > > On Thu, Apr 19, 2012 at 04:08:46PM +0200, Vasilis Liaskovitis wrote: > > > Hotplugged memory is not persistent in the e820 memory maps. After hotplugging > > > a memslot and rebooting the VM, the hotplugged device is not present. > > > > > > A possible solution is to add an e820 for the new memslot in the acpi_piix4 > > > hot-add handler. On a reset, Seabios (see next patch in series) will enable all > > > memory devices for which it finds an e820 entry that covers the devices's address > > > range. > > > > > > On hot-remove, the acpi_piix4 handler will try to remove the e820 entry > > > corresponding to the device. This will work when no VM reboots happen > > > between hot-add and hot-remove, but it is not a sufficient solution in > > > general: Seabios and GuestOS merge adjacent e820 entries on machine reboot, > > > so the sequence hot-add/ rebootVM / hot-remove will fail to remove a > > > corresponding e820 entry at the hot-remove phase. > > > > > Why do you need this path and the next one? Bios can restore the state > > of memslots and build e820 map by reading mems_sts. > > i see, that is a simpler solution. Since qemu currently creates most ram e820map Quite the contrary. Qemu creates only one entry that Seabios can't figure by itself. > entries and passes them to seabios, I tried to follow the same approach. But > your suggestion makes things easier and we don't have to worry about merged e820 > entries on hot-remove. I 'll rework it. > thanks, > > Vasilis -- Gleb.

1 0

Re: [SeaBIOS] [RFC PATCH 8/9] pc: adjust e820 map on hot-add and hot-remove
by Gleb Natapov 23 Apr '12

23 Apr '12

On Thu, Apr 19, 2012 at 04:08:46PM +0200, Vasilis Liaskovitis wrote: > Hotplugged memory is not persistent in the e820 memory maps. After hotplugging > a memslot and rebooting the VM, the hotplugged device is not present. > > A possible solution is to add an e820 for the new memslot in the acpi_piix4 > hot-add handler. On a reset, Seabios (see next patch in series) will enable all > memory devices for which it finds an e820 entry that covers the devices's address > range. > > On hot-remove, the acpi_piix4 handler will try to remove the e820 entry > corresponding to the device. This will work when no VM reboots happen > between hot-add and hot-remove, but it is not a sufficient solution in > general: Seabios and GuestOS merge adjacent e820 entries on machine reboot, > so the sequence hot-add/ rebootVM / hot-remove will fail to remove a > corresponding e820 entry at the hot-remove phase. > Why do you need this path and the next one? Bios can restore the state of memslots and build e820 map by reading mems_sts. > Signed-off-by: Vasilis Liaskovitis <vasilis.liaskovitis(a)profitbricks.com> > --- > hw/acpi_piix4.c | 6 ++++++ > hw/pc.c | 28 ++++++++++++++++++++++++++++ > hw/pc.h | 1 + > 3 files changed, 35 insertions(+), 0 deletions(-) > > diff --git a/hw/acpi_piix4.c b/hw/acpi_piix4.c > index 2921d18..2b5fd04 100644 > --- a/hw/acpi_piix4.c > +++ b/hw/acpi_piix4.c > @@ -619,6 +619,9 @@ static void piix4_memslot_eject(uint32_t addr, uint32_t val) > s = memslot_find_from_idx(start + idx); > assert(s != NULL); > memslot_depopulate(s); > + if (e820_del_entry(s->start, s->size, E820_RAM) == -EBUSY) > + PIIX4_DPRINTF("failed to remove e820 entry for memslot %u\n", > + s->idx); > } > val = val >> 1; > idx++; > @@ -634,6 +637,9 @@ static int piix4_memslot_hotplug(DeviceState *qdev, SysBusDevice *dev, int > > if (add) { > enable_mem_device(s, slot->idx); > + if (e820_add_entry(slot->start, slot->size, E820_RAM) == -EBUSY) > + PIIX4_DPRINTF("failed to add e820 entry for memslot %u\n", > + slot->idx); > } > else { > disable_mem_device(s, slot->idx); > diff --git a/hw/pc.c b/hw/pc.c > index f1f550a..04d243f 100644 > --- a/hw/pc.c > +++ b/hw/pc.c > @@ -593,6 +593,34 @@ int e820_add_entry(uint64_t address, uint64_t length, uint32_t type) > return index; > } > > +int e820_del_entry(uint64_t address, uint64_t length, uint32_t type) > +{ > + int index = le32_to_cpu(e820_table.count); > + int search; > + struct e820_entry *entry; > + > + if (index == 0) > + return -EBUSY; > + search = index - 1; > + entry = &e820_table.entry[search]; > + while (search >= 0) { > + if ((entry->address == cpu_to_le64(address)) && > + (entry->length == cpu_to_le64(length)) && > + (entry->type == cpu_to_le32(type))){ > + if (search != index - 1) { > + memcpy(&e820_table.entry[search], &e820_table.entry[search + 1], > + sizeof(struct e820_entry) * (index - search)); > + } > + index--; > + e820_table.count = cpu_to_le32(index); > + return 1; > + } > + search--; > + entry = &e820_table.entry[search]; > + } > + return -EBUSY; > +} > + > static void bochs_bios_setup_hp_memslots(uint64_t *fw_cfg_slots); > > static void *bochs_bios_init(void) > diff --git a/hw/pc.h b/hw/pc.h > index 74d3369..4925e8c 100644 > --- a/hw/pc.h > +++ b/hw/pc.h > @@ -226,5 +226,6 @@ void pc_system_firmware_init(MemoryRegion *rom_memory); > #define E820_UNUSABLE 5 > > int e820_add_entry(uint64_t, uint64_t, uint32_t); > +int e820_del_entry(uint64_t, uint64_t, uint32_t); > > #endif > -- > 1.7.9 -- Gleb.

2 1

Little help with call32
by Daniel Castro 23 Apr '12

23 Apr '12

Hello All, I have a small problem with call32, after I make the call and the 32bit code is executed the parameter I am sending is incorrect, so evidently I am doing something incorrect. Here is my 16bit code: dprintf(1,"Operation 16bit drive at %p\n",op->drive_g); extern void _cfunc32flat_xen_blk_op_read(struct disk_op_s *); return call32(_cfunc32flat_xen_blk_op_read,op,DISK_RET_EPARAM); Here is the 32Bit code: int VISIBLE32INIT xen_blk_op_read(struct disk_op_s *op){ dprintf(1,"Xen Disk buffer %x lba %x count %d command %d\n",op->buf_fl,op->lba,op->count,op->command); dprintf(1,"Searching for drive, loc: %p\n",op->drive_g); struct xendrive_s * xendrive = container_of(op->drive_g, struct xendrive_s, drive); //the global struct is extracted if(xendrive==NULL) return -1; ... } I know something is wrong because the output is like this: Operation 16bit drive at 0x0000d630 DEBUG call32: func 0x0f7e90a7 eax 832 err 1 Xen Disk buffer f000ff53 lba f000ff53 count -268370093 command 65363 Searching for drive, loc: 0xf000ff53 As you can see op->drive_g are located in different addreses in 16 and 32 bit modes. Can someone help me out to find where the mistake is. The code seems to be valid so I guess I am passing the pointer wrongly. Thanks, Daniel -- +-=====---------------------------+ | +---------------------------------+ | This space intentionally blank for notetaking. | | | Daniel Castro, | | | | Consultant/Programmer.| | | | U Andes | +-------------------------------------+

1 0

Re: [SeaBIOS] [Qemu-devel] [RFC PATCH 6/9] pc: pass paravirt info for hotplug memory slots to BIOS
by Igor Mammedov 20 Apr '12

20 Apr '12

On 04/19/2012 04:08 PM, Vasilis Liaskovitis wrote: > The numa_fw_cfg paravirt interface is extended to include SRAT information for > all hotplug-able memslots. There are 3 words for each hotplug-able memory slot, > denoting start address, size and node proximity. nb_numa_nodes is set to 1 by > default (not 0), so that we always pass srat info to SeaBIOS. > > This information is used by Seabios to build hotplug memory device objects at runtime. > > Signed-off-by: Vasilis Liaskovitis<vasilis.liaskovitis(a)profitbricks.com> > --- > hw/pc.c | 59 +++++++++++++++++++++++++++++++++++++++++++++++++++++------ > vl.c | 4 +++- > 2 files changed, 56 insertions(+), 7 deletions(-) > > diff --git a/hw/pc.c b/hw/pc.c > index 67f0479..f1f550a 100644 > --- a/hw/pc.c > +++ b/hw/pc.c > @@ -46,6 +46,7 @@ > #include "ui/qemu-spice.h" > #include "memory.h" > #include "exec-memory.h" > +#include "memslot.h" > > /* output Bochs bios info messages */ > //#define DEBUG_BIOS > @@ -592,12 +593,15 @@ int e820_add_entry(uint64_t address, uint64_t length, uint32_t type) > return index; > } > > +static void bochs_bios_setup_hp_memslots(uint64_t *fw_cfg_slots); > + > static void *bochs_bios_init(void) > { > void *fw_cfg; > uint8_t *smbios_table; > size_t smbios_len; > uint64_t *numa_fw_cfg; > + uint64_t *hp_memslots_fw_cfg; > int i, j; > > register_ioport_write(0x400, 1, 2, bochs_bios_write, NULL); > @@ -630,28 +634,71 @@ static void *bochs_bios_init(void) > fw_cfg_add_bytes(fw_cfg, FW_CFG_HPET, (uint8_t *)&hpet_cfg, > sizeof(struct hpet_fw_config)); > /* allocate memory for the NUMA channel: one (64bit) word for the number > - * of nodes, one word for each VCPU->node and one word for each node to > - * hold the amount of memory. > + * of nodes, one word for the number of hotplug memory slots, one word > + * for each VCPU->node, one word for each node to hold the amount of memory. > + * Finally three words for each hotplug memory slot, denoting start address, > + * size and node proximity. > */ > - numa_fw_cfg = g_malloc0((1 + max_cpus + nb_numa_nodes) * 8); > + numa_fw_cfg = g_malloc0((2 + max_cpus + nb_numa_nodes + 3 * nb_hp_memslots) * 8); > numa_fw_cfg[0] = cpu_to_le64(nb_numa_nodes); > + numa_fw_cfg[1] = cpu_to_le64(nb_hp_memslots); this will brake compatibility if guest was migrated from old->new qemu than on reboot it will use old bios that expects numa_fw_cfg[1] to be something else. Could memslots info be moved to the end of an existing interface? > + > for (i = 0; i< max_cpus; i++) { > for (j = 0; j< nb_numa_nodes; j++) { > if (node_cpumask[j]& (1<< i)) { > - numa_fw_cfg[i + 1] = cpu_to_le64(j); > + numa_fw_cfg[i + 2] = cpu_to_le64(j); > break; > } > } > } > for (i = 0; i< nb_numa_nodes; i++) { > - numa_fw_cfg[max_cpus + 1 + i] = cpu_to_le64(node_mem[i]); > + numa_fw_cfg[max_cpus + 2 + i] = cpu_to_le64(node_mem[i]); > } > + > + hp_memslots_fw_cfg = numa_fw_cfg + 2 + max_cpus + nb_numa_nodes; > + if (nb_hp_memslots) > + bochs_bios_setup_hp_memslots(hp_memslots_fw_cfg); > + > fw_cfg_add_bytes(fw_cfg, FW_CFG_NUMA, (uint8_t *)numa_fw_cfg, > - (1 + max_cpus + nb_numa_nodes) * 8); > + (2 + max_cpus + nb_numa_nodes + 3 * nb_hp_memslots) * 8); > > return fw_cfg; > } > > +static void bochs_bios_setup_hp_memslots(uint64_t *fw_cfg_slots) > +{ > + int i = 0; > + Error *err = NULL; > + DeviceState *dev; > + MemSlotState *slot; > + char *type; > + BusState *bus = sysbus_get_default(); > + > + QTAILQ_FOREACH(dev,&bus->children, sibling) { > + type = object_property_get_str(OBJECT(dev), "type",&err); > + if (err) { > + error_free(err); > + fprintf(stderr, "error getting device type\n"); > + exit(1); > + } > + > + if (!strcmp(type, "memslot")) { > + if (!dev->id) { > + error_free(err); > + fprintf(stderr, "error getting memslot device id\n"); > + exit(1); > + } > + if (!strcmp(dev->id, "initialslot")) continue; > + slot = MEMSLOT(dev); > + fw_cfg_slots[3 * slot->idx] = cpu_to_le64(slot->start); > + fw_cfg_slots[3 * slot->idx + 1] = cpu_to_le64(slot->size); > + fw_cfg_slots[3 * slot->idx + 2] = cpu_to_le64(slot->node); > + i++; > + } > + } > + assert(i == nb_hp_memslots); > +} > + > static long get_file_size(FILE *f) > { > long where, size; > diff --git a/vl.c b/vl.c > index ae91a8a..50df453 100644 > --- a/vl.c > +++ b/vl.c > @@ -3428,8 +3428,10 @@ int main(int argc, char **argv, char **envp) > > register_savevm_live(NULL, "ram", 0, 4, NULL, ram_save_live, NULL, > ram_load, NULL); > + if (!nb_numa_nodes) > + nb_numa_nodes = 1; > > - if (nb_numa_nodes> 0) { > + { > int i; > > if (nb_numa_nodes> MAX_NODES) { -- ----- Igor

2 1

Re: [SeaBIOS] [RFC PATCH 0/9] ACPI memory hotplug
by Vasilis Liaskovitis 20 Apr '12

20 Apr '12

On Thu, Apr 19, 2012 at 04:08:38PM +0200, Vasilis Liaskovitis wrote: > > series is based on uq/master for qemu-kvm, and master for seabios. Can be found > also at: forgot to paste the repo links in the original coverletter, here they are if someone wants them: https://github.com/vliaskov/qemu-kvm/commits/memory-hotplug https://github.com/vliaskov/seabios/commits/memory-hotplug thanks, - Vasilis

1 0

Re: [SeaBIOS] [Qemu-devel] [RFC PATCH 2/9] Implement acpi-dsdt functions for memory hotplug.
by Igor Mammedov 20 Apr '12

20 Apr '12

On 04/19/2012 04:08 PM, Vasilis Liaskovitis wrote: > Extend the DSDT to include methods for handling memory hot-add and hot-remove > notifications and memory device status requests. These functions are called > from the memory device SSDT methods. > > Eject has only been tested with level gpe event, but will be changed to edge gpe > event soon, according to recent master patch for other ACPI hotplug events. > > Signed-off-by: Vasilis Liaskovitis<vasilis.liaskovitis(a)profitbricks.com> > --- > src/acpi-dsdt.dsl | 68 +++++++++++++++++++++++++++++++++++++++++++++++++++- > 1 files changed, 66 insertions(+), 2 deletions(-) > > diff --git a/src/acpi-dsdt.dsl b/src/acpi-dsdt.dsl > index 4bdc268..184daf0 100644 > --- a/src/acpi-dsdt.dsl > +++ b/src/acpi-dsdt.dsl > @@ -709,9 +709,72 @@ DefinitionBlock ( > } > Return(One) > } > - } > > + /* Objects filled in by run-time generated SSDT */ > + External(MTFY, MethodObj) > + External(MEON, PkgObj) > + > + Method (CMST, 1, NotSerialized) { > + // _STA method - return ON status of memdevice > + // Local0 = MEON flag for this cpu > + Store(DerefOf(Index(MEON, Arg0)), Local0) > + If (Local0) { Return(0xF) } Else { Return(0x0) } > + } > + /* Memory eject notify method */ > + OperationRegion(MEMJ, SystemIO, 0xaf40, 32) > + Field (MEMJ, ByteAcc, NoLock, Preserve) > + { > + MPE, 256 > + } > + > + Method (MPEJ, 2, NotSerialized) { > + // _EJ0 method - eject callback > + Store(ShiftLeft(1,Arg0), MPE) > + Sleep(200) > + } MPE is write only and only one memslot is ejected at a time. Why 256 bit-field is here then? Could we use just 1 byte and write a slot number into it and save some io address space this way? > + > + /* Memory hotplug notify method */ > + OperationRegion(MEST, SystemIO, 0xaf20, 32) It's more a suggestion: move it a bit farther to allow maybe 1024 cpus in the future. That will prevent compatibility a headache, if we decide to expand support to more then 256 cpus. Or event better to make this address configurable in run-time and build this var along with SSDT (converting along the way all other hard-coded io ports to the same generic run-time interface). This wish is out of scope of this patch-set, but what do you think about the idea? > + Field (MEST, ByteAcc, NoLock, Preserve) > + { > + MES, 256 > + } > + > + Method(MESC, 0) { > + // Local5 = active memdevice bitmap > + Store (MES, Local5) > + // Local2 = last read byte from bitmap > + Store (Zero, Local2) > + // Local0 = memory device iterator > + Store (Zero, Local0) > + While (LLess(Local0, SizeOf(MEON))) { > + // Local1 = MEON flag for this memory device > + Store(DerefOf(Index(MEON, Local0)), Local1) > + If (And(Local0, 0x07)) { > + // Shift down previously read bitmap byte > + ShiftRight(Local2, 1, Local2) > + } Else { > + // Read next byte from memdevice bitmap > + Store(DerefOf(Index(Local5, ShiftRight(Local0, 3))), Local2) > + } > + // Local3 = active state for this memory device > + Store(And(Local2, 1), Local3) > > + If (LNotEqual(Local1, Local3)) { > + // State change - update MEON with new state > + Store(Local3, Index(MEON, Local0)) > + // Do MEM notify > + If (LEqual(Local3, 1)) { > + MTFY(Local0, 1) > + } Else { > + MTFY(Local0, 3) > + } > + } > + Increment(Local0) > + } > + Return(One) > + } > + } > /**************************************************************** > * General purpose events > ****************************************************************/ > @@ -732,7 +795,8 @@ DefinitionBlock ( > Return(\_SB.PRSC()) > } > Method(_L03) { > - Return(0x01) > + // Memory hotplug event > + Return(\_SB.MESC()) > } > Method(_L04) { > Return(0x01) -- ----- Igor

2 1

[PATCH 0/4] Redesign of pciinit.c (take 3)
by Alexey Korolev 20 Apr '12

20 Apr '12

Hi, This patch series redesigns the existing pciinit.c code and introduces linked list operations. Changes are more about structures definitions rather than functionality. There are no more arrays of bases and counts in new implementation. The new implementation is based on dynamic allocation of pci_region_entry structures. Each pci_region_entry structure could be a PCI bar or a downstream PCI region (bridge). Each entry has a set of attributes: type (IO, MEM, PREFMEM), is64bit, size, base address, PCI device owner, and a pointer to the pci_bus it belongs to. 1. Introduce List operations 2. Add pci_region_entry and linked lists operations in place while still using the array system to do the allocations. 3. Switch to lists operations 4. Get rid of size element from bus->r structure, now we use entry->size for the same purpose src/pci.h | 5 - src/pciinit.c | 258 ++++++++++++++++++++++++++------------------------------- src/util.h | 21 +++++ 3 files changed, 137 insertions(+), 147 deletions(-)

5 19

Re: [SeaBIOS] [RFC PATCH 7/9] Implement memslot command-line option and memslot hmp command
by Avi Kivity 19 Apr '12

19 Apr '12

On 04/19/2012 05:08 PM, Vasilis Liaskovitis wrote: > Implement -memslot qemu-kvm command line option to define hotplug-able memory > slots. > Syntax: "-memslot id=name,start=addr,size=sz,node=nodeid" > > e.g. "-memslot id=hot1,start=4294967296,size=1073741824,node=0" > will define a 1G memory slot starting at physical address 4G, belonging to numa > node 0. Defining no node will automatically add a memslot to node 0. start=4G,size=1G ought to work too, no? -- error compiling committee.c: too many arguments to function

2 1

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

SeaBIOS April 2012