SeaBIOS

seabios@seabios.org

4 participants
3801 discussions

Re: [SeaBIOS] Little help with call32
by Kevin O'Connor 26 Apr '12

26 Apr '12

On Mon, Apr 23, 2012 at 03:51:10PM +0900, Daniel Castro wrote: > 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); The 'op' structure is on the stack and the pointer is therefore relative to the stack segment. Use MAKE_FLATPTR to construct a 32bit pointer - see pci_writel() for an example. -Kevin

2 1

Re: [SeaBIOS] [RFC PATCH 9/9] enable memory devices if e820 entry is present
by Wen Congyang 26 Apr '12

26 Apr '12

At 04/19/2012 10:08 PM, Vasilis Liaskovitis Wrote: > On a reboot, seabios regenerates srat/ssdt objects. If a valid e820 entry is > found spanning the whole address range of a hotplug memory device, the device > will be enabled. This ensures persistency of hotplugged memory slots across VM > reboots. > > Signed-off-by: Vasilis Liaskovitis <vasilis.liaskovitis(a)profitbricks.com> > --- > src/acpi.c | 6 +++++- > src/memmap.c | 15 +++++++++++++++ > 2 files changed, 20 insertions(+), 1 deletions(-) > > diff --git a/src/acpi.c b/src/acpi.c > index 5580099..2ebed2e 100644 > --- a/src/acpi.c > +++ b/src/acpi.c > @@ -601,7 +601,11 @@ build_memssdt(void) > for (i = 0; i < nb_memdevs; i++) { > mem_base = (((u64)(entry->base_addr_high) << 32 )| entry->base_addr_low); > mem_len = (((u64)(entry->length_high) << 32 )| entry->length_low); > - *(ssdt_ptr++) = 0x00; > + if (find_e820(mem_base, mem_len, E820_RAM)) { This line will break the building: Compilation complete. 0 Errors, 16 Warnings, 0 Remarks, 259 Optimizations Compiling whole program out/ccode32flat.o src/acpi.c: In function ‘build_memssdt’: src/acpi.c:604: warning: implicit declaration of function ‘find_e820’ src/memmap.c:137: note: previous definition of ‘find_e820’ was here src/acpi.c:604: error: ‘E820_RAM’ undeclared (first use in this function) src/acpi.c:604: error: (Each undeclared identifier is reported only once src/acpi.c:604: error: for each function it appears in.) make: *** [out/ccode32flat.o] Error 1 You should declare the function find_e820() in src/memmap.h and include this header file in src/acpi.c. Thanks Wen Congyang > + *(ssdt_ptr++) = 0x01; > + } > + else > + *(ssdt_ptr++) = 0x00; > entry++; > } > build_header((void*)ssdt, SSDT_SIGNATURE, ssdt_ptr - ssdt, 1); > diff --git a/src/memmap.c b/src/memmap.c > index 56865b4..9790da1 100644 > --- a/src/memmap.c > +++ b/src/memmap.c > @@ -131,6 +131,21 @@ add_e820(u64 start, u64 size, u32 type) > //dump_map(); > } > > +// Check if an e820 entry exists that covers the memory range > +// [start, start+size) with same type as type. > +int > +find_e820(u64 start, u64 size, u32 type) > +{ > + int i; > + for (i=0; i<e820_count; i++) { > + struct e820entry *e = &e820_list[i]; > + if ((e->start <= start) && (e->size >= (size + start - e->start)) && > + (e->type == type)) > + return 1; > + } > + return 0; > +} > + > // Report on final memory locations. > void > memmap_finalize(void)

1 0

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

24 Apr '12

On Thu, Apr 19, 2012 at 04:08:38PM +0200, Vasilis Liaskovitis wrote: > 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 We can add ,populated=true to -memslot to make slot populated from the 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. > > - 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 -- Gleb.

3 8

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

24 Apr '12

On Tue, Apr 24, 2012 at 10:24:51AM +0200, Vasilis Liaskovitis wrote: > Hi, > On Tue, Apr 24, 2012 at 10:52:24AM +0300, Gleb Natapov wrote: > > On Mon, Apr 23, 2012 at 02:31:15PM +0200, Vasilis Liaskovitis wrote: > > > 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? > yes, this was redundant with the original concept. > > > 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. > > I agree -m should mean one big unpluggable slot. > > So in the new proposal,"-device dimm populated=true" means a hot-removable dimm > that has already been hotplugged. > Yes. > A question here is when exactly should the initial hot-add event for this dimm > be played? If the relevant OSPM has not yet been initialized (e.g. acpi_memhotplug > module in a linux guest needs to be loaded), the guest may not see the event. > This is a general issue of course, but with initially populated hot-removable > dimms it may be a bigger issue. Can ospm acpi initialization be detected? > > Or maybe you are suggesting "populated=true" is part of initial memory (i.e. not > hot-added, but still hot-removable). Though in that case guestOS may use it for > bootmem allocations, making hot-remove more likely to fail at the memory > offlining stage. > If memory slot is populated even before OSPM is started BIOS will detect that by reading mem_sts and will create e820 map appropriately. OSPM will detect it by evaluating _STA during boot. This is not unique for memory hot-plug. Any hotpluggable device have the same issue. -- Gleb.

1 0

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

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

SeaBIOS