* [Qemu-devel] [PULL 1/8] cpu: add cpu_physical_memory_clear_dirty_range_nocode
2014-12-24 11:51 [Qemu-devel] [PULL 0/8] pc: resizeable ROM blocks Michael S. Tsirkin
@ 2014-12-24 11:51 ` Michael S. Tsirkin
2015-01-07 7:16 ` Paolo Bonzini
2014-12-24 11:51 ` [Qemu-devel] [PULL 2/8] memory: add memory_region_set_size Michael S. Tsirkin
` (7 subsequent siblings)
8 siblings, 1 reply; 22+ messages in thread
From: Michael S. Tsirkin @ 2014-12-24 11:51 UTC (permalink / raw)
To: qemu-devel
Cc: Peter Maydell, Juan Quintela, dgilbert, Orit Wasserman,
Paolo Bonzini
simple wrapper so callers don't need to know about
dirty bitmap clients.
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
---
include/exec/ram_addr.h | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/include/exec/ram_addr.h b/include/exec/ram_addr.h
index 8fc75cd..18ec092 100644
--- a/include/exec/ram_addr.h
+++ b/include/exec/ram_addr.h
@@ -184,6 +184,14 @@ static inline void cpu_physical_memory_clear_dirty_range(ram_addr_t start,
bitmap_clear(ram_list.dirty_memory[client], page, end - page);
}
+static inline void cpu_physical_memory_clear_dirty_range_nocode(ram_addr_t start,
+ ram_addr_t length)
+{
+ cpu_physical_memory_clear_dirty_range(start, length, DIRTY_MEMORY_MIGRATION);
+ cpu_physical_memory_clear_dirty_range(start, length, DIRTY_MEMORY_VGA);
+}
+
+
void cpu_physical_memory_reset_dirty(ram_addr_t start, ram_addr_t length,
unsigned client);
--
MST
^ permalink raw reply related [flat|nested] 22+ messages in thread
* Re: [Qemu-devel] [PULL 1/8] cpu: add cpu_physical_memory_clear_dirty_range_nocode
2014-12-24 11:51 ` [Qemu-devel] [PULL 1/8] cpu: add cpu_physical_memory_clear_dirty_range_nocode Michael S. Tsirkin
@ 2015-01-07 7:16 ` Paolo Bonzini
0 siblings, 0 replies; 22+ messages in thread
From: Paolo Bonzini @ 2015-01-07 7:16 UTC (permalink / raw)
To: qemu-devel; +Cc: Peter Maydell, Orit Wasserman, dgilbert, Juan Quintela
On 24/12/2014 12:51, Michael S. Tsirkin wrote:
> simple wrapper so callers don't need to know about
> dirty bitmap clients.
>
> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
> ---
> include/exec/ram_addr.h | 8 ++++++++
> 1 file changed, 8 insertions(+)
>
> diff --git a/include/exec/ram_addr.h b/include/exec/ram_addr.h
> index 8fc75cd..18ec092 100644
> --- a/include/exec/ram_addr.h
> +++ b/include/exec/ram_addr.h
> @@ -184,6 +184,14 @@ static inline void cpu_physical_memory_clear_dirty_range(ram_addr_t start,
> bitmap_clear(ram_list.dirty_memory[client], page, end - page);
> }
>
> +static inline void cpu_physical_memory_clear_dirty_range_nocode(ram_addr_t start,
> + ram_addr_t length)
> +{
> + cpu_physical_memory_clear_dirty_range(start, length, DIRTY_MEMORY_MIGRATION);
> + cpu_physical_memory_clear_dirty_range(start, length, DIRTY_MEMORY_VGA);
> +}
> +
> +
> void cpu_physical_memory_reset_dirty(ram_addr_t start, ram_addr_t length,
> unsigned client);
>
>
The function is not used and goes away in patch 3, so squash it there.
Paolo
^ permalink raw reply [flat|nested] 22+ messages in thread
* [Qemu-devel] [PULL 2/8] memory: add memory_region_set_size
2014-12-24 11:51 [Qemu-devel] [PULL 0/8] pc: resizeable ROM blocks Michael S. Tsirkin
2014-12-24 11:51 ` [Qemu-devel] [PULL 1/8] cpu: add cpu_physical_memory_clear_dirty_range_nocode Michael S. Tsirkin
@ 2014-12-24 11:51 ` Michael S. Tsirkin
2014-12-24 11:51 ` [Qemu-devel] [PULL 3/8] exec: cpu_physical_memory_set/clear_dirty_range Michael S. Tsirkin
` (6 subsequent siblings)
8 siblings, 0 replies; 22+ messages in thread
From: Michael S. Tsirkin @ 2014-12-24 11:51 UTC (permalink / raw)
To: qemu-devel; +Cc: Peter Maydell, Paolo Bonzini, dgilbert, Juan Quintela
Add API to change MR size.
Will be used internally for RAM resize.
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
---
include/exec/memory.h | 10 ++++++++++
memory.c | 16 ++++++++++++++++
2 files changed, 26 insertions(+)
diff --git a/include/exec/memory.h b/include/exec/memory.h
index f64ab5e..0882221 100644
--- a/include/exec/memory.h
+++ b/include/exec/memory.h
@@ -878,6 +878,16 @@ void memory_region_set_enabled(MemoryRegion *mr, bool enabled);
void memory_region_set_address(MemoryRegion *mr, hwaddr addr);
/*
+ * memory_region_set_size: dynamically update the size of a region.
+ *
+ * Dynamically updates the size of a region.
+ *
+ * @mr: the region to be updated
+ * @size: used size of the region.
+ */
+void memory_region_set_size(MemoryRegion *mr, uint64_t size);
+
+/*
* memory_region_set_alias_offset: dynamically update a memory alias's offset
*
* Dynamically updates the offset into the target region that an alias points
diff --git a/memory.c b/memory.c
index 15cf9eb..618470b 100644
--- a/memory.c
+++ b/memory.c
@@ -1707,6 +1707,22 @@ void memory_region_set_enabled(MemoryRegion *mr, bool enabled)
memory_region_transaction_commit();
}
+void memory_region_set_size(MemoryRegion *mr, uint64_t size)
+{
+ Int128 s = int128_make64(size);
+
+ if (size == UINT64_MAX) {
+ s = int128_2_64();
+ }
+ if (int128_eq(s, mr->size)) {
+ return;
+ }
+ memory_region_transaction_begin();
+ mr->size = s;
+ memory_region_update_pending = true;
+ memory_region_transaction_commit();
+}
+
static void memory_region_readd_subregion(MemoryRegion *mr)
{
MemoryRegion *container = mr->container;
--
MST
^ permalink raw reply related [flat|nested] 22+ messages in thread
* [Qemu-devel] [PULL 3/8] exec: cpu_physical_memory_set/clear_dirty_range
2014-12-24 11:51 [Qemu-devel] [PULL 0/8] pc: resizeable ROM blocks Michael S. Tsirkin
2014-12-24 11:51 ` [Qemu-devel] [PULL 1/8] cpu: add cpu_physical_memory_clear_dirty_range_nocode Michael S. Tsirkin
2014-12-24 11:51 ` [Qemu-devel] [PULL 2/8] memory: add memory_region_set_size Michael S. Tsirkin
@ 2014-12-24 11:51 ` Michael S. Tsirkin
2014-12-24 11:51 ` [Qemu-devel] [PULL 4/8] exec: split length -> used_length/max_length Michael S. Tsirkin
` (5 subsequent siblings)
8 siblings, 0 replies; 22+ messages in thread
From: Michael S. Tsirkin @ 2014-12-24 11:51 UTC (permalink / raw)
To: qemu-devel; +Cc: Peter Maydell, Paolo Bonzini, dgilbert, Juan Quintela
Make cpu_physical_memory_set/clear_dirty_range
behave symmetrically.
To clear range for a given client type only, add
cpu_physical_memory_clear_dirty_range_type.
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
---
include/exec/ram_addr.h | 15 ++++++++-------
exec.c | 2 +-
2 files changed, 9 insertions(+), 8 deletions(-)
diff --git a/include/exec/ram_addr.h b/include/exec/ram_addr.h
index 18ec092..254931c 100644
--- a/include/exec/ram_addr.h
+++ b/include/exec/ram_addr.h
@@ -172,9 +172,9 @@ static inline void cpu_physical_memory_set_dirty_lebitmap(unsigned long *bitmap,
}
#endif /* not _WIN32 */
-static inline void cpu_physical_memory_clear_dirty_range(ram_addr_t start,
- ram_addr_t length,
- unsigned client)
+static inline void cpu_physical_memory_clear_dirty_range_type(ram_addr_t start,
+ ram_addr_t length,
+ unsigned client)
{
unsigned long end, page;
@@ -184,11 +184,12 @@ static inline void cpu_physical_memory_clear_dirty_range(ram_addr_t start,
bitmap_clear(ram_list.dirty_memory[client], page, end - page);
}
-static inline void cpu_physical_memory_clear_dirty_range_nocode(ram_addr_t start,
- ram_addr_t length)
+static inline void cpu_physical_memory_clear_dirty_range(ram_addr_t start,
+ ram_addr_t length)
{
- cpu_physical_memory_clear_dirty_range(start, length, DIRTY_MEMORY_MIGRATION);
- cpu_physical_memory_clear_dirty_range(start, length, DIRTY_MEMORY_VGA);
+ cpu_physical_memory_clear_dirty_range_type(start, length, DIRTY_MEMORY_MIGRATION);
+ cpu_physical_memory_clear_dirty_range_type(start, length, DIRTY_MEMORY_VGA);
+ cpu_physical_memory_clear_dirty_range_type(start, length, DIRTY_MEMORY_CODE);
}
diff --git a/exec.c b/exec.c
index 963481a..a89aa6c 100644
--- a/exec.c
+++ b/exec.c
@@ -850,7 +850,7 @@ void cpu_physical_memory_reset_dirty(ram_addr_t start, ram_addr_t length,
{
if (length == 0)
return;
- cpu_physical_memory_clear_dirty_range(start, length, client);
+ cpu_physical_memory_clear_dirty_range_type(start, length, client);
if (tcg_enabled()) {
tlb_reset_dirty_range_all(start, length);
--
MST
^ permalink raw reply related [flat|nested] 22+ messages in thread
* [Qemu-devel] [PULL 4/8] exec: split length -> used_length/max_length
2014-12-24 11:51 [Qemu-devel] [PULL 0/8] pc: resizeable ROM blocks Michael S. Tsirkin
` (2 preceding siblings ...)
2014-12-24 11:51 ` [Qemu-devel] [PULL 3/8] exec: cpu_physical_memory_set/clear_dirty_range Michael S. Tsirkin
@ 2014-12-24 11:51 ` Michael S. Tsirkin
2014-12-24 11:51 ` [Qemu-devel] [PULL 5/8] exec: qemu_ram_alloc_resizeable, qemu_ram_resize Michael S. Tsirkin
` (4 subsequent siblings)
8 siblings, 0 replies; 22+ messages in thread
From: Michael S. Tsirkin @ 2014-12-24 11:51 UTC (permalink / raw)
To: qemu-devel
Cc: Amit Shah, Peter Maydell, Paolo Bonzini, dgilbert, Juan Quintela
This patch allows us to distinguish between two
length values for each block:
max_length - length of memory block that was allocated
used_length - length of block used by QEMU/guest
Currently, we set used_length - max_length, unconditionally.
Follow-up patches allow used_length <= max_length.
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
---
include/exec/cpu-all.h | 3 ++-
arch_init.c | 19 +++++++++---------
exec.c | 52 +++++++++++++++++++++++++++-----------------------
3 files changed, 40 insertions(+), 34 deletions(-)
diff --git a/include/exec/cpu-all.h b/include/exec/cpu-all.h
index 62f5581..6f2130e 100644
--- a/include/exec/cpu-all.h
+++ b/include/exec/cpu-all.h
@@ -303,7 +303,8 @@ typedef struct RAMBlock {
struct MemoryRegion *mr;
uint8_t *host;
ram_addr_t offset;
- ram_addr_t length;
+ ram_addr_t used_length;
+ ram_addr_t max_length;
uint32_t flags;
char idstr[256];
/* Reads can take either the iothread or the ramlist lock.
diff --git a/arch_init.c b/arch_init.c
index 7680d28..106f46e 100644
--- a/arch_init.c
+++ b/arch_init.c
@@ -522,7 +522,7 @@ static void migration_bitmap_sync(void)
address_space_sync_dirty_bitmap(&address_space_memory);
QTAILQ_FOREACH(block, &ram_list.blocks, next) {
- migration_bitmap_sync_range(block->mr->ram_addr, block->length);
+ migration_bitmap_sync_range(block->mr->ram_addr, block->used_length);
}
trace_migration_bitmap_sync_end(migration_dirty_pages
- num_dirty_pages_init);
@@ -668,7 +668,7 @@ static int ram_find_and_save_block(QEMUFile *f, bool last_stage)
offset >= last_offset) {
break;
}
- if (offset >= block->length) {
+ if (offset >= block->used_length) {
offset = 0;
block = QTAILQ_NEXT(block, next);
if (!block) {
@@ -727,7 +727,7 @@ uint64_t ram_bytes_total(void)
uint64_t total = 0;
QTAILQ_FOREACH(block, &ram_list.blocks, next)
- total += block->length;
+ total += block->used_length;
return total;
}
@@ -831,7 +831,7 @@ static int ram_save_setup(QEMUFile *f, void *opaque)
QTAILQ_FOREACH(block, &ram_list.blocks, next) {
uint64_t block_pages;
- block_pages = block->length >> TARGET_PAGE_BITS;
+ block_pages = block->used_length >> TARGET_PAGE_BITS;
migration_dirty_pages += block_pages;
}
@@ -844,7 +844,7 @@ static int ram_save_setup(QEMUFile *f, void *opaque)
QTAILQ_FOREACH(block, &ram_list.blocks, next) {
qemu_put_byte(f, strlen(block->idstr));
qemu_put_buffer(f, (uint8_t *)block->idstr, strlen(block->idstr));
- qemu_put_be64(f, block->length);
+ qemu_put_be64(f, block->used_length);
}
qemu_mutex_unlock_ramlist();
@@ -1015,7 +1015,7 @@ static inline void *host_from_stream_offset(QEMUFile *f,
uint8_t len;
if (flags & RAM_SAVE_FLAG_CONTINUE) {
- if (!block || block->length <= offset) {
+ if (!block || block->max_length <= offset) {
error_report("Ack, bad migration stream!");
return NULL;
}
@@ -1028,7 +1028,8 @@ static inline void *host_from_stream_offset(QEMUFile *f,
id[len] = 0;
QTAILQ_FOREACH(block, &ram_list.blocks, next) {
- if (!strncmp(id, block->idstr, sizeof(id)) && block->length > offset) {
+ if (!strncmp(id, block->idstr, sizeof(id)) &&
+ block->max_length > offset) {
return memory_region_get_ram_ptr(block->mr) + offset;
}
}
@@ -1085,10 +1086,10 @@ static int ram_load(QEMUFile *f, void *opaque, int version_id)
QTAILQ_FOREACH(block, &ram_list.blocks, next) {
if (!strncmp(id, block->idstr, sizeof(id))) {
- if (block->length != length) {
+ if (block->used_length != length) {
error_report("Length mismatch: %s: 0x" RAM_ADDR_FMT
" in != 0x" RAM_ADDR_FMT, id, length,
- block->length);
+ block->used_length);
ret = -EINVAL;
}
break;
diff --git a/exec.c b/exec.c
index a89aa6c..b69216a 100644
--- a/exec.c
+++ b/exec.c
@@ -812,11 +812,11 @@ static RAMBlock *qemu_get_ram_block(ram_addr_t addr)
/* The list is protected by the iothread lock here. */
block = ram_list.mru_block;
- if (block && addr - block->offset < block->length) {
+ if (block && addr - block->offset < block->max_length) {
goto found;
}
QTAILQ_FOREACH(block, &ram_list.blocks, next) {
- if (addr - block->offset < block->length) {
+ if (addr - block->offset < block->max_length) {
goto found;
}
}
@@ -1305,13 +1305,14 @@ static ram_addr_t ram_block_add(RAMBlock *new_block, Error **errp)
/* This assumes the iothread lock is taken here too. */
qemu_mutex_lock_ramlist();
- new_block->offset = find_ram_offset(new_block->length);
+ new_block->offset = find_ram_offset(new_block->max_length);
if (!new_block->host) {
if (xen_enabled()) {
- xen_ram_alloc(new_block->offset, new_block->length, new_block->mr);
+ xen_ram_alloc(new_block->offset, new_block->max_length,
+ new_block->mr);
} else {
- new_block->host = phys_mem_alloc(new_block->length,
+ new_block->host = phys_mem_alloc(new_block->max_length,
&new_block->mr->align);
if (!new_block->host) {
error_setg_errno(errp, errno,
@@ -1320,13 +1321,13 @@ static ram_addr_t ram_block_add(RAMBlock *new_block, Error **errp)
qemu_mutex_unlock_ramlist();
return -1;
}
- memory_try_enable_merging(new_block->host, new_block->length);
+ memory_try_enable_merging(new_block->host, new_block->max_length);
}
}
/* Keep the list sorted from biggest to smallest block. */
QTAILQ_FOREACH(block, &ram_list.blocks, next) {
- if (block->length < new_block->length) {
+ if (block->max_length < new_block->max_length) {
break;
}
}
@@ -1350,14 +1351,15 @@ static ram_addr_t ram_block_add(RAMBlock *new_block, Error **errp)
old_ram_size, new_ram_size);
}
}
- cpu_physical_memory_set_dirty_range(new_block->offset, new_block->length);
+ cpu_physical_memory_set_dirty_range(new_block->offset,
+ new_block->used_length);
- qemu_ram_setup_dump(new_block->host, new_block->length);
- qemu_madvise(new_block->host, new_block->length, QEMU_MADV_HUGEPAGE);
- qemu_madvise(new_block->host, new_block->length, QEMU_MADV_DONTFORK);
+ qemu_ram_setup_dump(new_block->host, new_block->max_length);
+ qemu_madvise(new_block->host, new_block->max_length, QEMU_MADV_HUGEPAGE);
+ qemu_madvise(new_block->host, new_block->max_length, QEMU_MADV_DONTFORK);
if (kvm_enabled()) {
- kvm_setup_guest_memory(new_block->host, new_block->length);
+ kvm_setup_guest_memory(new_block->host, new_block->max_length);
}
return new_block->offset;
@@ -1391,7 +1393,8 @@ ram_addr_t qemu_ram_alloc_from_file(ram_addr_t size, MemoryRegion *mr,
size = TARGET_PAGE_ALIGN(size);
new_block = g_malloc0(sizeof(*new_block));
new_block->mr = mr;
- new_block->length = size;
+ new_block->used_length = size;
+ new_block->max_length = size;
new_block->flags = share ? RAM_SHARED : 0;
new_block->host = file_ram_alloc(new_block, size,
mem_path, errp);
@@ -1420,7 +1423,8 @@ ram_addr_t qemu_ram_alloc_from_ptr(ram_addr_t size, void *host,
size = TARGET_PAGE_ALIGN(size);
new_block = g_malloc0(sizeof(*new_block));
new_block->mr = mr;
- new_block->length = size;
+ new_block->used_length = size;
+ new_block->max_length = max_size;
new_block->fd = -1;
new_block->host = host;
if (host) {
@@ -1475,11 +1479,11 @@ void qemu_ram_free(ram_addr_t addr)
xen_invalidate_map_cache_entry(block->host);
#ifndef _WIN32
} else if (block->fd >= 0) {
- munmap(block->host, block->length);
+ munmap(block->host, block->max_length);
close(block->fd);
#endif
} else {
- qemu_anon_ram_free(block->host, block->length);
+ qemu_anon_ram_free(block->host, block->max_length);
}
g_free(block);
break;
@@ -1499,7 +1503,7 @@ void qemu_ram_remap(ram_addr_t addr, ram_addr_t length)
QTAILQ_FOREACH(block, &ram_list.blocks, next) {
offset = addr - block->offset;
- if (offset < block->length) {
+ if (offset < block->max_length) {
vaddr = ramblock_ptr(block, offset);
if (block->flags & RAM_PREALLOC) {
;
@@ -1575,7 +1579,7 @@ void *qemu_get_ram_ptr(ram_addr_t addr)
return xen_map_cache(addr, 0, 0);
} else if (block->host == NULL) {
block->host =
- xen_map_cache(block->offset, block->length, 1);
+ xen_map_cache(block->offset, block->max_length, 1);
}
}
return ramblock_ptr(block, addr - block->offset);
@@ -1594,9 +1598,9 @@ static void *qemu_ram_ptr_length(ram_addr_t addr, hwaddr *size)
RAMBlock *block;
QTAILQ_FOREACH(block, &ram_list.blocks, next) {
- if (addr - block->offset < block->length) {
- if (addr - block->offset + *size > block->length)
- *size = block->length - addr + block->offset;
+ if (addr - block->offset < block->max_length) {
+ if (addr - block->offset + *size > block->max_length)
+ *size = block->max_length - addr + block->offset;
return ramblock_ptr(block, addr - block->offset);
}
}
@@ -1619,7 +1623,7 @@ MemoryRegion *qemu_ram_addr_from_host(void *ptr, ram_addr_t *ram_addr)
}
block = ram_list.mru_block;
- if (block && block->host && host - block->host < block->length) {
+ if (block && block->host && host - block->host < block->max_length) {
goto found;
}
@@ -1628,7 +1632,7 @@ MemoryRegion *qemu_ram_addr_from_host(void *ptr, ram_addr_t *ram_addr)
if (block->host == NULL) {
continue;
}
- if (host - block->host < block->length) {
+ if (host - block->host < block->max_length) {
goto found;
}
}
@@ -2873,7 +2877,7 @@ void qemu_ram_foreach_block(RAMBlockIterFunc func, void *opaque)
RAMBlock *block;
QTAILQ_FOREACH(block, &ram_list.blocks, next) {
- func(block->host, block->offset, block->length, opaque);
+ func(block->host, block->offset, block->used_length, opaque);
}
}
#endif
--
MST
^ permalink raw reply related [flat|nested] 22+ messages in thread
* [Qemu-devel] [PULL 5/8] exec: qemu_ram_alloc_resizeable, qemu_ram_resize
2014-12-24 11:51 [Qemu-devel] [PULL 0/8] pc: resizeable ROM blocks Michael S. Tsirkin
` (3 preceding siblings ...)
2014-12-24 11:51 ` [Qemu-devel] [PULL 4/8] exec: split length -> used_length/max_length Michael S. Tsirkin
@ 2014-12-24 11:51 ` Michael S. Tsirkin
2015-01-07 7:18 ` Paolo Bonzini
2014-12-24 11:51 ` [Qemu-devel] [PULL 6/8] arch_init: support resizing on incoming migration Michael S. Tsirkin
` (3 subsequent siblings)
8 siblings, 1 reply; 22+ messages in thread
From: Michael S. Tsirkin @ 2014-12-24 11:51 UTC (permalink / raw)
To: qemu-devel; +Cc: Peter Maydell, Paolo Bonzini, dgilbert, Juan Quintela
Add API to allocate "resizeable" RAM.
This looks just like regular RAM generally, but
has a special property that only a portion of it
(used_length) is actually used, and migrated.
This used_length size can change across reboots.
Follow up patches will change used_length for such blocks at migration,
making it easier to extend devices using such RAM (notably ACPI,
but in the future thinkably other ROMs) without breaking migration
compatibility or wasting ROM (guest) memory.
Device is notified on resize, so it can adjust if necessary.
qemu_ram_alloc_resizeable allocates this memory, qemu_ram_resize resizes
it.
Note: nothing prevents making all RAM resizeable in this way.
However, reviewers felt that only enabling this selectively will
make some class of errors easier to detect.
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
---
include/exec/cpu-all.h | 9 ++++--
include/exec/ram_addr.h | 7 +++++
exec.c | 75 ++++++++++++++++++++++++++++++++++++++++++++++---
3 files changed, 84 insertions(+), 7 deletions(-)
diff --git a/include/exec/cpu-all.h b/include/exec/cpu-all.h
index 6f2130e..7ced147 100644
--- a/include/exec/cpu-all.h
+++ b/include/exec/cpu-all.h
@@ -299,12 +299,15 @@ CPUArchState *cpu_copy(CPUArchState *env);
/* memory API */
-typedef struct RAMBlock {
+typedef struct RAMBlock RAMBlock;
+
+struct RAMBlock {
struct MemoryRegion *mr;
uint8_t *host;
ram_addr_t offset;
ram_addr_t used_length;
ram_addr_t max_length;
+ void (*resized)(const char*, uint64_t length, void *host);
uint32_t flags;
char idstr[256];
/* Reads can take either the iothread or the ramlist lock.
@@ -312,11 +315,11 @@ typedef struct RAMBlock {
*/
QTAILQ_ENTRY(RAMBlock) next;
int fd;
-} RAMBlock;
+};
static inline void *ramblock_ptr(RAMBlock *block, ram_addr_t offset)
{
- assert(offset < block->length);
+ assert(offset < block->used_length);
assert(block->host);
return (char *)block->host + offset;
}
diff --git a/include/exec/ram_addr.h b/include/exec/ram_addr.h
index 254931c..ff558a4 100644
--- a/include/exec/ram_addr.h
+++ b/include/exec/ram_addr.h
@@ -28,12 +28,19 @@ ram_addr_t qemu_ram_alloc_from_file(ram_addr_t size, MemoryRegion *mr,
ram_addr_t qemu_ram_alloc_from_ptr(ram_addr_t size, void *host,
MemoryRegion *mr, Error **errp);
ram_addr_t qemu_ram_alloc(ram_addr_t size, MemoryRegion *mr, Error **errp);
+ram_addr_t qemu_ram_alloc_resizeable(ram_addr_t size, ram_addr_t max_size,
+ void (*resized)(const char*,
+ uint64_t length,
+ void *host),
+ MemoryRegion *mr, Error **errp);
int qemu_get_ram_fd(ram_addr_t addr);
void *qemu_get_ram_block_host_ptr(ram_addr_t addr);
void *qemu_get_ram_ptr(ram_addr_t addr);
void qemu_ram_free(ram_addr_t addr);
void qemu_ram_free_from_ptr(ram_addr_t addr);
+int qemu_ram_resize(ram_addr_t base, ram_addr_t newsize, Error **errp);
+
static inline bool cpu_physical_memory_get_dirty(ram_addr_t start,
ram_addr_t length,
unsigned client)
diff --git a/exec.c b/exec.c
index b69216a..2427319 100644
--- a/exec.c
+++ b/exec.c
@@ -75,6 +75,11 @@ static MemoryRegion io_mem_unassigned;
/* RAM is mmap-ed with MAP_SHARED */
#define RAM_SHARED (1 << 1)
+/* On-device RAM allocated with g_malloc: supports realloc,
+ * not accessible to vcpu on kvm.
+ */
+#define RAM_RESIZEABLE (1 << 2)
+
#endif
struct CPUTailQ cpus = QTAILQ_HEAD_INITIALIZER(cpus);
@@ -1186,7 +1191,7 @@ static ram_addr_t find_ram_offset(ram_addr_t size)
QTAILQ_FOREACH(block, &ram_list.blocks, next) {
ram_addr_t end, next = RAM_ADDR_MAX;
- end = block->offset + block->length;
+ end = block->offset + block->max_length;
QTAILQ_FOREACH(next_block, &ram_list.blocks, next) {
if (next_block->offset >= end) {
@@ -1214,7 +1219,7 @@ ram_addr_t last_ram_offset(void)
ram_addr_t last = 0;
QTAILQ_FOREACH(block, &ram_list.blocks, next)
- last = MAX(last, block->offset + block->length);
+ last = MAX(last, block->offset + block->max_length);
return last;
}
@@ -1296,6 +1301,42 @@ static int memory_try_enable_merging(void *addr, size_t len)
return qemu_madvise(addr, len, QEMU_MADV_MERGEABLE);
}
+int qemu_ram_resize(ram_addr_t base, ram_addr_t newsize, Error **errp)
+{
+ RAMBlock *block = find_ram_block(base);
+
+ assert(block);
+
+ if (block->used_length == newsize) {
+ return 0;
+ }
+
+ if (!(block->flags & RAM_RESIZEABLE)) {
+ error_setg_errno(errp, EINVAL,
+ "Length mismatch: %s: 0x" RAM_ADDR_FMT
+ " in != 0x" RAM_ADDR_FMT, block->idstr,
+ newsize, block->used_length);
+ return -EINVAL;
+ }
+
+ if (block->max_length < newsize) {
+ error_setg_errno(errp, EINVAL,
+ "Length too large: %s: 0x" RAM_ADDR_FMT
+ " > 0x" RAM_ADDR_FMT, block->idstr,
+ newsize, block->max_length);
+ return -EINVAL;
+ }
+
+ cpu_physical_memory_clear_dirty_range(block->offset, block->used_length);
+ block->used_length = newsize;
+ cpu_physical_memory_set_dirty_range(block->offset, block->used_length);
+ memory_region_set_size(block->mr, newsize);
+ if (block->resized) {
+ block->resized(block->idstr, newsize, block->host);
+ }
+ return 0;
+}
+
static ram_addr_t ram_block_add(RAMBlock *new_block, Error **errp)
{
RAMBlock *block;
@@ -1413,7 +1454,12 @@ ram_addr_t qemu_ram_alloc_from_file(ram_addr_t size, MemoryRegion *mr,
}
#endif
-ram_addr_t qemu_ram_alloc_from_ptr(ram_addr_t size, void *host,
+static
+ram_addr_t qemu_ram_alloc_internal(ram_addr_t size, ram_addr_t max_size,
+ void (*resized)(const char*,
+ uint64_t length,
+ void *host),
+ void *host, bool resizeable,
MemoryRegion *mr, Error **errp)
{
RAMBlock *new_block;
@@ -1421,15 +1467,21 @@ ram_addr_t qemu_ram_alloc_from_ptr(ram_addr_t size, void *host,
Error *local_err = NULL;
size = TARGET_PAGE_ALIGN(size);
+ max_size = TARGET_PAGE_ALIGN(max_size);
new_block = g_malloc0(sizeof(*new_block));
new_block->mr = mr;
+ new_block->resized = resized;
new_block->used_length = size;
new_block->max_length = max_size;
+ assert(max_size >= size);
new_block->fd = -1;
new_block->host = host;
if (host) {
new_block->flags |= RAM_PREALLOC;
}
+ if (resizeable) {
+ new_block->flags |= RAM_RESIZEABLE;
+ }
addr = ram_block_add(new_block, &local_err);
if (local_err) {
g_free(new_block);
@@ -1439,9 +1491,24 @@ ram_addr_t qemu_ram_alloc_from_ptr(ram_addr_t size, void *host,
return addr;
}
+ram_addr_t qemu_ram_alloc_from_ptr(ram_addr_t size, void *host,
+ MemoryRegion *mr, Error **errp)
+{
+ return qemu_ram_alloc_internal(size, size, NULL, host, false, mr, errp);
+}
+
ram_addr_t qemu_ram_alloc(ram_addr_t size, MemoryRegion *mr, Error **errp)
{
- return qemu_ram_alloc_from_ptr(size, NULL, mr, errp);
+ return qemu_ram_alloc_internal(size, size, NULL, NULL, false, mr, errp);
+}
+
+ram_addr_t qemu_ram_alloc_resizeable(ram_addr_t size, ram_addr_t maxsz,
+ void (*resized)(const char*,
+ uint64_t length,
+ void *host),
+ MemoryRegion *mr, Error **errp)
+{
+ return qemu_ram_alloc_internal(size, maxsz, resized, NULL, true, mr, errp);
}
void qemu_ram_free_from_ptr(ram_addr_t addr)
--
MST
^ permalink raw reply related [flat|nested] 22+ messages in thread
* Re: [Qemu-devel] [PULL 5/8] exec: qemu_ram_alloc_resizeable, qemu_ram_resize
2014-12-24 11:51 ` [Qemu-devel] [PULL 5/8] exec: qemu_ram_alloc_resizeable, qemu_ram_resize Michael S. Tsirkin
@ 2015-01-07 7:18 ` Paolo Bonzini
2015-01-07 9:55 ` Michael S. Tsirkin
0 siblings, 1 reply; 22+ messages in thread
From: Paolo Bonzini @ 2015-01-07 7:18 UTC (permalink / raw)
To: Michael S. Tsirkin, qemu-devel; +Cc: Peter Maydell, dgilbert, Juan Quintela
On 24/12/2014 12:51, Michael S. Tsirkin wrote:
> +/* On-device RAM allocated with g_malloc: supports realloc,
> + * not accessible to vcpu on kvm.
> + */
Is this still true?
Paolo
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [Qemu-devel] [PULL 5/8] exec: qemu_ram_alloc_resizeable, qemu_ram_resize
2015-01-07 7:18 ` Paolo Bonzini
@ 2015-01-07 9:55 ` Michael S. Tsirkin
0 siblings, 0 replies; 22+ messages in thread
From: Michael S. Tsirkin @ 2015-01-07 9:55 UTC (permalink / raw)
To: Paolo Bonzini; +Cc: Peter Maydell, Juan Quintela, qemu-devel, dgilbert
On Wed, Jan 07, 2015 at 08:18:02AM +0100, Paolo Bonzini wrote:
>
>
> On 24/12/2014 12:51, Michael S. Tsirkin wrote:
> > +/* On-device RAM allocated with g_malloc: supports realloc,
> > + * not accessible to vcpu on kvm.
> > + */
>
> Is this still true?
>
> Paolo
No! Will drop.
^ permalink raw reply [flat|nested] 22+ messages in thread
* [Qemu-devel] [PULL 6/8] arch_init: support resizing on incoming migration
2014-12-24 11:51 [Qemu-devel] [PULL 0/8] pc: resizeable ROM blocks Michael S. Tsirkin
` (4 preceding siblings ...)
2014-12-24 11:51 ` [Qemu-devel] [PULL 5/8] exec: qemu_ram_alloc_resizeable, qemu_ram_resize Michael S. Tsirkin
@ 2014-12-24 11:51 ` Michael S. Tsirkin
2014-12-24 11:51 ` [Qemu-devel] [PULL 7/8] memory: API to allocate resizeable RAM MR Michael S. Tsirkin
` (2 subsequent siblings)
8 siblings, 0 replies; 22+ messages in thread
From: Michael S. Tsirkin @ 2014-12-24 11:51 UTC (permalink / raw)
To: qemu-devel; +Cc: Amit Shah, Peter Maydell, dgilbert, Juan Quintela
If block used_length does not match, try to resize it.
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
---
arch_init.c | 13 ++++++++-----
1 file changed, 8 insertions(+), 5 deletions(-)
diff --git a/arch_init.c b/arch_init.c
index 106f46e..cfedbf0 100644
--- a/arch_init.c
+++ b/arch_init.c
@@ -1086,11 +1086,14 @@ static int ram_load(QEMUFile *f, void *opaque, int version_id)
QTAILQ_FOREACH(block, &ram_list.blocks, next) {
if (!strncmp(id, block->idstr, sizeof(id))) {
- if (block->used_length != length) {
- error_report("Length mismatch: %s: 0x" RAM_ADDR_FMT
- " in != 0x" RAM_ADDR_FMT, id, length,
- block->used_length);
- ret = -EINVAL;
+ if (length != block->used_length) {
+ Error *local_err = NULL;
+
+ ret = qemu_ram_resize(block->offset, length, &local_err);
+ if (local_err) {
+ error_report("%s", error_get_pretty(local_err));
+ error_free(local_err);
+ }
}
break;
}
--
MST
^ permalink raw reply related [flat|nested] 22+ messages in thread
* [Qemu-devel] [PULL 7/8] memory: API to allocate resizeable RAM MR
2014-12-24 11:51 [Qemu-devel] [PULL 0/8] pc: resizeable ROM blocks Michael S. Tsirkin
` (5 preceding siblings ...)
2014-12-24 11:51 ` [Qemu-devel] [PULL 6/8] arch_init: support resizing on incoming migration Michael S. Tsirkin
@ 2014-12-24 11:51 ` Michael S. Tsirkin
2014-12-24 11:51 ` [Qemu-devel] [PULL 8/8] acpi-build: make ROMs RAM blocks resizeable Michael S. Tsirkin
2014-12-24 12:25 ` [Qemu-devel] [PULL 0/8] pc: resizeable ROM blocks Paolo Bonzini
8 siblings, 0 replies; 22+ messages in thread
From: Michael S. Tsirkin @ 2014-12-24 11:51 UTC (permalink / raw)
To: qemu-devel; +Cc: Peter Maydell, Paolo Bonzini, dgilbert, Juan Quintela
Add API to allocate resizeable RAM MR.
This looks just like regular RAM generally, but
has a special property that only a portion of it
(used_length) is actually used, and migrated.
This used_length size can change across reboots.
Follow up patches will change used_length for such blocks at migration,
making it easier to extend devices using such RAM (notably ACPI,
but in the future thinkably other ROMs) without breaking migration
compatibility or wasting ROM (guest) memory.
Device is notified on resize, so it can adjust if necessary.
Note: nothing prevents making all RAM resizeable in this way.
However, reviewers felt that only enabling this selectively will
make some class of errors easier to detect.
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
---
include/exec/memory.h | 24 ++++++++++++++++++++++++
memory.c | 17 +++++++++++++++++
2 files changed, 41 insertions(+)
diff --git a/include/exec/memory.h b/include/exec/memory.h
index 0882221..0cd96b1 100644
--- a/include/exec/memory.h
+++ b/include/exec/memory.h
@@ -321,6 +321,30 @@ void memory_region_init_ram(MemoryRegion *mr,
uint64_t size,
Error **errp);
+/**
+ * memory_region_init_resizeable_ram: Initialize memory region with resizeable
+ * RAM. Accesses into the region will
+ * modify memory directly. Only an initial
+ * portion of this RAM is actually used.
+ * The used size can change across reboots.
+ *
+ * @mr: the #MemoryRegion to be initialized.
+ * @owner: the object that tracks the region's reference count
+ * @name: the name of the region.
+ * @size: used size of the region.
+ * @max_size: max size of the region.
+ * @resized: callback to notify owner about used size change.
+ * @errp: pointer to Error*, to store an error if it happens.
+ */
+void memory_region_init_resizeable_ram(MemoryRegion *mr,
+ struct Object *owner,
+ const char *name,
+ uint64_t size,
+ uint64_t max_size,
+ void (*resized)(const char*,
+ uint64_t length,
+ void *host),
+ Error **errp);
#ifdef __linux__
/**
* memory_region_init_ram_from_file: Initialize RAM memory region with a
diff --git a/memory.c b/memory.c
index 618470b..c343bf3 100644
--- a/memory.c
+++ b/memory.c
@@ -1152,6 +1152,23 @@ void memory_region_init_ram(MemoryRegion *mr,
mr->ram_addr = qemu_ram_alloc(size, mr, errp);
}
+void memory_region_init_resizeable_ram(MemoryRegion *mr,
+ Object *owner,
+ const char *name,
+ uint64_t size,
+ uint64_t max_size,
+ void (*resized)(const char*,
+ uint64_t length,
+ void *host),
+ Error **errp)
+{
+ memory_region_init(mr, owner, name, size);
+ mr->ram = true;
+ mr->terminates = true;
+ mr->destructor = memory_region_destructor_ram;
+ mr->ram_addr = qemu_ram_alloc_resizeable(size, max_size, resized, mr, errp);
+}
+
#ifdef __linux__
void memory_region_init_ram_from_file(MemoryRegion *mr,
struct Object *owner,
--
MST
^ permalink raw reply related [flat|nested] 22+ messages in thread
* [Qemu-devel] [PULL 8/8] acpi-build: make ROMs RAM blocks resizeable
2014-12-24 11:51 [Qemu-devel] [PULL 0/8] pc: resizeable ROM blocks Michael S. Tsirkin
` (6 preceding siblings ...)
2014-12-24 11:51 ` [Qemu-devel] [PULL 7/8] memory: API to allocate resizeable RAM MR Michael S. Tsirkin
@ 2014-12-24 11:51 ` Michael S. Tsirkin
2014-12-30 13:47 ` Marcel Apfelbaum
2014-12-24 12:25 ` [Qemu-devel] [PULL 0/8] pc: resizeable ROM blocks Paolo Bonzini
8 siblings, 1 reply; 22+ messages in thread
From: Michael S. Tsirkin @ 2014-12-24 11:51 UTC (permalink / raw)
To: qemu-devel
Cc: Peter Maydell, Juan Quintela, dgilbert, Michael Walle,
Anthony Liguori, Paolo Bonzini, Richard Henderson
Use resizeable ram API so we can painlessly extend ROMs in the
future. Note: migration is not affected, as we are
not actually changing the used length for RAM, which
is the part that's migrated.
Use this in acpi: reserve x16 more RAM space.
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
---
hw/lm32/lm32_hwsetup.h | 3 ++-
include/hw/loader.h | 4 ++--
hw/core/loader.c | 18 ++++++++++++++----
hw/i386/acpi-build.c | 19 ++++++++++++++-----
4 files changed, 32 insertions(+), 12 deletions(-)
diff --git a/hw/lm32/lm32_hwsetup.h b/hw/lm32/lm32_hwsetup.h
index 9fd5e69..838754d 100644
--- a/hw/lm32/lm32_hwsetup.h
+++ b/hw/lm32/lm32_hwsetup.h
@@ -73,7 +73,8 @@ static inline void hwsetup_free(HWSetup *hw)
static inline void hwsetup_create_rom(HWSetup *hw,
hwaddr base)
{
- rom_add_blob("hwsetup", hw->data, TARGET_PAGE_SIZE, base, NULL, NULL, NULL);
+ rom_add_blob("hwsetup", hw->data, TARGET_PAGE_SIZE,
+ TARGET_PAGE_SIZE, base, NULL, NULL, NULL);
}
static inline void hwsetup_add_u8(HWSetup *hw, uint8_t u)
diff --git a/include/hw/loader.h b/include/hw/loader.h
index 6481639..1d76108 100644
--- a/include/hw/loader.h
+++ b/include/hw/loader.h
@@ -60,7 +60,7 @@ int rom_add_file(const char *file, const char *fw_dir,
hwaddr addr, int32_t bootindex,
bool option_rom);
ram_addr_t rom_add_blob(const char *name, const void *blob, size_t len,
- hwaddr addr, const char *fw_file_name,
+ size_t max_len, hwaddr addr, const char *fw_file_name,
FWCfgReadCallback fw_callback, void *callback_opaque);
int rom_add_elf_program(const char *name, void *data, size_t datasize,
size_t romsize, hwaddr addr);
@@ -74,7 +74,7 @@ void do_info_roms(Monitor *mon, const QDict *qdict);
#define rom_add_file_fixed(_f, _a, _i) \
rom_add_file(_f, NULL, _a, _i, false)
#define rom_add_blob_fixed(_f, _b, _l, _a) \
- rom_add_blob(_f, _b, _l, _a, NULL, NULL, NULL)
+ rom_add_blob(_f, _b, _l, _l, _a, NULL, NULL, NULL)
#define PC_ROM_MIN_VGA 0xc0000
#define PC_ROM_MIN_OPTION 0xc8000
diff --git a/hw/core/loader.c b/hw/core/loader.c
index 7527fd3..d3f8501 100644
--- a/hw/core/loader.c
+++ b/hw/core/loader.c
@@ -712,12 +712,22 @@ static void rom_insert(Rom *rom)
QTAILQ_INSERT_TAIL(&roms, rom, next);
}
+static void fw_cfg_resized(const char *id, uint64_t length, void *host)
+{
+ if (fw_cfg) {
+ fw_cfg_modify_file(fw_cfg, id + strlen("/rom@"), host, length);
+ }
+}
+
static void *rom_set_mr(Rom *rom, Object *owner, const char *name)
{
void *data;
rom->mr = g_malloc(sizeof(*rom->mr));
- memory_region_init_ram(rom->mr, owner, name, rom->datasize, &error_abort);
+ memory_region_init_resizeable_ram(rom->mr, owner, name,
+ rom->datasize, rom->romsize,
+ fw_cfg_resized,
+ &error_abort);
memory_region_set_readonly(rom->mr, true);
vmstate_register_ram_global(rom->mr);
@@ -812,7 +822,7 @@ err:
}
ram_addr_t rom_add_blob(const char *name, const void *blob, size_t len,
- hwaddr addr, const char *fw_file_name,
+ size_t max_len, hwaddr addr, const char *fw_file_name,
FWCfgReadCallback fw_callback, void *callback_opaque)
{
Rom *rom;
@@ -821,7 +831,7 @@ ram_addr_t rom_add_blob(const char *name, const void *blob, size_t len,
rom = g_malloc0(sizeof(*rom));
rom->name = g_strdup(name);
rom->addr = addr;
- rom->romsize = len;
+ rom->romsize = max_len ? max_len : len;
rom->datasize = len;
rom->data = g_malloc0(rom->datasize);
memcpy(rom->data, blob, len);
@@ -841,7 +851,7 @@ ram_addr_t rom_add_blob(const char *name, const void *blob, size_t len,
fw_cfg_add_file_callback(fw_cfg, fw_file_name,
fw_callback, callback_opaque,
- data, rom->romsize);
+ data, rom->datasize);
}
return ret;
}
diff --git a/hw/i386/acpi-build.c b/hw/i386/acpi-build.c
index a4d0c0c..6a2e9c5 100644
--- a/hw/i386/acpi-build.c
+++ b/hw/i386/acpi-build.c
@@ -68,6 +68,9 @@
#define ACPI_BUILD_TABLE_SIZE 0x20000
+/* Reserve RAM space for tables: add another order of magnitude. */
+#define ACPI_BUILD_TABLE_MAX_SIZE 0x200000
+
/* #define DEBUG_ACPI_BUILD */
#ifdef DEBUG_ACPI_BUILD
#define ACPI_BUILD_DPRINTF(fmt, ...) \
@@ -1718,6 +1721,11 @@ static void acpi_build_update(void *build_opaque, uint32_t offset)
acpi_build(build_state->guest_info, &tables);
assert(acpi_data_len(tables.table_data) == build_state->table_size);
+
+ /* Make sure RAM size is correct - in case it got changed by migration */
+ qemu_ram_resize(build_state->table_ram, build_state->table_size,
+ &error_abort);
+
memcpy(qemu_get_ram_ptr(build_state->table_ram), tables.table_data->data,
build_state->table_size);
@@ -1734,10 +1742,10 @@ static void acpi_build_reset(void *build_opaque)
}
static ram_addr_t acpi_add_rom_blob(AcpiBuildState *build_state, GArray *blob,
- const char *name)
+ const char *name, uint64_t max_size)
{
- return rom_add_blob(name, blob->data, acpi_data_len(blob), -1, name,
- acpi_build_update, build_state);
+ return rom_add_blob(name, blob->data, acpi_data_len(blob), max_size, -1,
+ name, acpi_build_update, build_state);
}
static const VMStateDescription vmstate_acpi_build = {
@@ -1781,11 +1789,12 @@ void acpi_setup(PcGuestInfo *guest_info)
/* Now expose it all to Guest */
build_state->table_ram = acpi_add_rom_blob(build_state, tables.table_data,
- ACPI_BUILD_TABLE_FILE);
+ ACPI_BUILD_TABLE_FILE,
+ ACPI_BUILD_TABLE_MAX_SIZE);
assert(build_state->table_ram != RAM_ADDR_MAX);
build_state->table_size = acpi_data_len(tables.table_data);
- acpi_add_rom_blob(NULL, tables.linker, "etc/table-loader");
+ acpi_add_rom_blob(NULL, tables.linker, "etc/table-loader", 0);
fw_cfg_add_file(guest_info->fw_cfg, ACPI_BUILD_TPMLOG_FILE,
tables.tcpalog->data, acpi_data_len(tables.tcpalog));
--
MST
^ permalink raw reply related [flat|nested] 22+ messages in thread
* Re: [Qemu-devel] [PULL 8/8] acpi-build: make ROMs RAM blocks resizeable
2014-12-24 11:51 ` [Qemu-devel] [PULL 8/8] acpi-build: make ROMs RAM blocks resizeable Michael S. Tsirkin
@ 2014-12-30 13:47 ` Marcel Apfelbaum
0 siblings, 0 replies; 22+ messages in thread
From: Marcel Apfelbaum @ 2014-12-30 13:47 UTC (permalink / raw)
To: Michael S. Tsirkin, qemu-devel
Cc: Peter Maydell, Juan Quintela, dgilbert, Michael Walle,
Anthony Liguori, Paolo Bonzini, Richard Henderson
On 12/24/2014 01:51 PM, Michael S. Tsirkin wrote:
> Use resizeable ram API so we can painlessly extend ROMs in the
> future. Note: migration is not affected, as we are
> not actually changing the used length for RAM, which
> is the part that's migrated.
>
> Use this in acpi: reserve x16 more RAM space.
>
> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
> ---
> hw/lm32/lm32_hwsetup.h | 3 ++-
> include/hw/loader.h | 4 ++--
> hw/core/loader.c | 18 ++++++++++++++----
> hw/i386/acpi-build.c | 19 ++++++++++++++-----
> 4 files changed, 32 insertions(+), 12 deletions(-)
>
> diff --git a/hw/lm32/lm32_hwsetup.h b/hw/lm32/lm32_hwsetup.h
> index 9fd5e69..838754d 100644
> --- a/hw/lm32/lm32_hwsetup.h
> +++ b/hw/lm32/lm32_hwsetup.h
> @@ -73,7 +73,8 @@ static inline void hwsetup_free(HWSetup *hw)
> static inline void hwsetup_create_rom(HWSetup *hw,
> hwaddr base)
> {
> - rom_add_blob("hwsetup", hw->data, TARGET_PAGE_SIZE, base, NULL, NULL, NULL);
> + rom_add_blob("hwsetup", hw->data, TARGET_PAGE_SIZE,
> + TARGET_PAGE_SIZE, base, NULL, NULL, NULL);
> }
>
> static inline void hwsetup_add_u8(HWSetup *hw, uint8_t u)
> diff --git a/include/hw/loader.h b/include/hw/loader.h
> index 6481639..1d76108 100644
> --- a/include/hw/loader.h
> +++ b/include/hw/loader.h
> @@ -60,7 +60,7 @@ int rom_add_file(const char *file, const char *fw_dir,
> hwaddr addr, int32_t bootindex,
> bool option_rom);
> ram_addr_t rom_add_blob(const char *name, const void *blob, size_t len,
> - hwaddr addr, const char *fw_file_name,
> + size_t max_len, hwaddr addr, const char *fw_file_name,
> FWCfgReadCallback fw_callback, void *callback_opaque);
> int rom_add_elf_program(const char *name, void *data, size_t datasize,
> size_t romsize, hwaddr addr);
> @@ -74,7 +74,7 @@ void do_info_roms(Monitor *mon, const QDict *qdict);
> #define rom_add_file_fixed(_f, _a, _i) \
> rom_add_file(_f, NULL, _a, _i, false)
> #define rom_add_blob_fixed(_f, _b, _l, _a) \
> - rom_add_blob(_f, _b, _l, _a, NULL, NULL, NULL)
> + rom_add_blob(_f, _b, _l, _l, _a, NULL, NULL, NULL)
>
> #define PC_ROM_MIN_VGA 0xc0000
> #define PC_ROM_MIN_OPTION 0xc8000
> diff --git a/hw/core/loader.c b/hw/core/loader.c
> index 7527fd3..d3f8501 100644
> --- a/hw/core/loader.c
> +++ b/hw/core/loader.c
> @@ -712,12 +712,22 @@ static void rom_insert(Rom *rom)
> QTAILQ_INSERT_TAIL(&roms, rom, next);
> }
>
> +static void fw_cfg_resized(const char *id, uint64_t length, void *host)
> +{
> + if (fw_cfg) {
> + fw_cfg_modify_file(fw_cfg, id + strlen("/rom@"), host, length);
> + }
> +}
> +
> static void *rom_set_mr(Rom *rom, Object *owner, const char *name)
> {
> void *data;
>
> rom->mr = g_malloc(sizeof(*rom->mr));
> - memory_region_init_ram(rom->mr, owner, name, rom->datasize, &error_abort);
> + memory_region_init_resizeable_ram(rom->mr, owner, name,
> + rom->datasize, rom->romsize,
> + fw_cfg_resized,
> + &error_abort);
> memory_region_set_readonly(rom->mr, true);
> vmstate_register_ram_global(rom->mr);
>
> @@ -812,7 +822,7 @@ err:
> }
>
> ram_addr_t rom_add_blob(const char *name, const void *blob, size_t len,
> - hwaddr addr, const char *fw_file_name,
> + size_t max_len, hwaddr addr, const char *fw_file_name,
> FWCfgReadCallback fw_callback, void *callback_opaque)
> {
> Rom *rom;
> @@ -821,7 +831,7 @@ ram_addr_t rom_add_blob(const char *name, const void *blob, size_t len,
> rom = g_malloc0(sizeof(*rom));
> rom->name = g_strdup(name);
> rom->addr = addr;
> - rom->romsize = len;
> + rom->romsize = max_len ? max_len : len;
> rom->datasize = len;
> rom->data = g_malloc0(rom->datasize);
> memcpy(rom->data, blob, len);
> @@ -841,7 +851,7 @@ ram_addr_t rom_add_blob(const char *name, const void *blob, size_t len,
>
> fw_cfg_add_file_callback(fw_cfg, fw_file_name,
> fw_callback, callback_opaque,
> - data, rom->romsize);
> + data, rom->datasize);
> }
> return ret;
> }
> diff --git a/hw/i386/acpi-build.c b/hw/i386/acpi-build.c
> index a4d0c0c..6a2e9c5 100644
> --- a/hw/i386/acpi-build.c
> +++ b/hw/i386/acpi-build.c
> @@ -68,6 +68,9 @@
>
> #define ACPI_BUILD_TABLE_SIZE 0x20000
>
> +/* Reserve RAM space for tables: add another order of magnitude. */
> +#define ACPI_BUILD_TABLE_MAX_SIZE 0x200000
> +
> /* #define DEBUG_ACPI_BUILD */
> #ifdef DEBUG_ACPI_BUILD
> #define ACPI_BUILD_DPRINTF(fmt, ...) \
> @@ -1718,6 +1721,11 @@ static void acpi_build_update(void *build_opaque, uint32_t offset)
> acpi_build(build_state->guest_info, &tables);
>
> assert(acpi_data_len(tables.table_data) == build_state->table_size);
> +
> + /* Make sure RAM size is correct - in case it got changed by migration */
> + qemu_ram_resize(build_state->table_ram, build_state->table_size,
> + &error_abort);
I also need this functionality for an ongoing series, in which the SSDT
table changes its size between the first "build" and after the bios computes
the io/mem regions.
> +
> memcpy(qemu_get_ram_ptr(build_state->table_ram), tables.table_data->data,
> build_state->table_size);
>
> @@ -1734,10 +1742,10 @@ static void acpi_build_reset(void *build_opaque)
> }
>
> static ram_addr_t acpi_add_rom_blob(AcpiBuildState *build_state, GArray *blob,
> - const char *name)
> + const char *name, uint64_t max_size)
> {
> - return rom_add_blob(name, blob->data, acpi_data_len(blob), -1, name,
> - acpi_build_update, build_state);
> + return rom_add_blob(name, blob->data, acpi_data_len(blob), max_size, -1,
> + name, acpi_build_update, build_state);
> }
>
> static const VMStateDescription vmstate_acpi_build = {
> @@ -1781,11 +1789,12 @@ void acpi_setup(PcGuestInfo *guest_info)
>
> /* Now expose it all to Guest */
> build_state->table_ram = acpi_add_rom_blob(build_state, tables.table_data,
> - ACPI_BUILD_TABLE_FILE);
> + ACPI_BUILD_TABLE_FILE,
> + ACPI_BUILD_TABLE_MAX_SIZE);
> assert(build_state->table_ram != RAM_ADDR_MAX);
> build_state->table_size = acpi_data_len(tables.table_data);
>
> - acpi_add_rom_blob(NULL, tables.linker, "etc/table-loader");
> + acpi_add_rom_blob(NULL, tables.linker, "etc/table-loader", 0);
>
> fw_cfg_add_file(guest_info->fw_cfg, ACPI_BUILD_TPMLOG_FILE,
> tables.tcpalog->data, acpi_data_len(tables.tcpalog));
>
Acked-by: Marcel Apfelbaum <marcel@redhat.com>
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [Qemu-devel] [PULL 0/8] pc: resizeable ROM blocks
2014-12-24 11:51 [Qemu-devel] [PULL 0/8] pc: resizeable ROM blocks Michael S. Tsirkin
` (7 preceding siblings ...)
2014-12-24 11:51 ` [Qemu-devel] [PULL 8/8] acpi-build: make ROMs RAM blocks resizeable Michael S. Tsirkin
@ 2014-12-24 12:25 ` Paolo Bonzini
2014-12-24 12:40 ` Peter Maydell
2014-12-24 12:41 ` Michael S. Tsirkin
8 siblings, 2 replies; 22+ messages in thread
From: Paolo Bonzini @ 2014-12-24 12:25 UTC (permalink / raw)
To: Michael S. Tsirkin, qemu-devel
Cc: Peter Maydell, Juan Quintela, dgilbert, imammedo
On 24/12/2014 12:51, Michael S. Tsirkin wrote:
> The following changes since commit d86fb03469e016af4e54f04efccbc20a8afa3e19:
>
> Merge remote-tracking branch 'remotes/spice/tags/pull-spice-20141216-1' into staging (2014-12-16 16:52:42 +0000)
>
> are available in the git repository at:
>
> git://git.kernel.org/pub/scm/virt/kvm/mst/qemu.git tags/for_upstream
>
> for you to fetch changes up to de101bf0e5b1f2bb7759074021f1e082752428ef:
>
> acpi-build: make ROMs RAM blocks resizeable (2014-12-16 22:14:11 +0200)
>
> ----------------------------------------------------------------
> pc: resizeable ROM blocks
>
> This makes ROM blocks resizeable. This infrastructure is required for other
> functionality we have queued.
>
> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
>
> ----------------------------------------------------------------
> Michael S. Tsirkin (8):
> cpu: add cpu_physical_memory_clear_dirty_range_nocode
> memory: add memory_region_set_size
> exec: cpu_physical_memory_set/clear_dirty_range
> exec: split length -> used_length/max_length
> exec: qemu_ram_alloc_resizeable, qemu_ram_resize
> arch_init: support resizing on incoming migration
> memory: API to allocate resizeable RAM MR
> acpi-build: make ROMs RAM blocks resizeable
>
> hw/lm32/lm32_hwsetup.h | 3 +-
> include/exec/cpu-all.h | 12 +++--
> include/exec/memory.h | 34 +++++++++++++
> include/exec/ram_addr.h | 22 +++++++--
> include/hw/loader.h | 4 +-
> arch_init.c | 28 ++++++-----
> exec.c | 129 +++++++++++++++++++++++++++++++++++++-----------
> hw/core/loader.c | 18 +++++--
> hw/i386/acpi-build.c | 19 +++++--
> memory.c | 33 +++++++++++++
> 10 files changed, 242 insertions(+), 60 deletions(-)
>
>
>
I don't think these are necessary, and I thought these were just RFC
when they were posted. I and mst didn't really understand each other,
and I take the fault for not reviewing the submission; however, Peter,
please hold these for a little more.
Paolo
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [Qemu-devel] [PULL 0/8] pc: resizeable ROM blocks
2014-12-24 12:25 ` [Qemu-devel] [PULL 0/8] pc: resizeable ROM blocks Paolo Bonzini
@ 2014-12-24 12:40 ` Peter Maydell
2014-12-24 12:41 ` Michael S. Tsirkin
1 sibling, 0 replies; 22+ messages in thread
From: Peter Maydell @ 2014-12-24 12:40 UTC (permalink / raw)
To: Paolo Bonzini
Cc: Igor Mammedov, Juan Quintela, QEMU Developers,
Dr. David Alan Gilbert, Michael S. Tsirkin
On 24 December 2014 at 12:25, Paolo Bonzini <pbonzini@redhat.com> wrote:
> On 24/12/2014 12:51, Michael S. Tsirkin wrote:
>> ----------------------------------------------------------------
>> pc: resizeable ROM blocks
>>
>> This makes ROM blocks resizeable. This infrastructure is required for other
>> functionality we have queued.
>>
>> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
> I don't think these are necessary, and I thought these were just RFC
> when they were posted. I and mst didn't really understand each other,
> and I take the fault for not reviewing the submission; however, Peter,
> please hold these for a little more.
Sure, no problem.
-- PMM
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [Qemu-devel] [PULL 0/8] pc: resizeable ROM blocks
2014-12-24 12:25 ` [Qemu-devel] [PULL 0/8] pc: resizeable ROM blocks Paolo Bonzini
2014-12-24 12:40 ` Peter Maydell
@ 2014-12-24 12:41 ` Michael S. Tsirkin
2015-01-07 7:33 ` Paolo Bonzini
1 sibling, 1 reply; 22+ messages in thread
From: Michael S. Tsirkin @ 2014-12-24 12:41 UTC (permalink / raw)
To: Paolo Bonzini
Cc: Peter Maydell, Juan Quintela, qemu-devel, dgilbert, imammedo
On Wed, Dec 24, 2014 at 01:25:16PM +0100, Paolo Bonzini wrote:
> On 24/12/2014 12:51, Michael S. Tsirkin wrote:
> > The following changes since commit d86fb03469e016af4e54f04efccbc20a8afa3e19:
> >
> > Merge remote-tracking branch 'remotes/spice/tags/pull-spice-20141216-1' into staging (2014-12-16 16:52:42 +0000)
> >
> > are available in the git repository at:
> >
> > git://git.kernel.org/pub/scm/virt/kvm/mst/qemu.git tags/for_upstream
> >
> > for you to fetch changes up to de101bf0e5b1f2bb7759074021f1e082752428ef:
> >
> > acpi-build: make ROMs RAM blocks resizeable (2014-12-16 22:14:11 +0200)
> >
> > ----------------------------------------------------------------
> > pc: resizeable ROM blocks
> >
> > This makes ROM blocks resizeable. This infrastructure is required for other
> > functionality we have queued.
> >
> > Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
> >
> > ----------------------------------------------------------------
> > Michael S. Tsirkin (8):
> > cpu: add cpu_physical_memory_clear_dirty_range_nocode
> > memory: add memory_region_set_size
> > exec: cpu_physical_memory_set/clear_dirty_range
> > exec: split length -> used_length/max_length
> > exec: qemu_ram_alloc_resizeable, qemu_ram_resize
> > arch_init: support resizing on incoming migration
> > memory: API to allocate resizeable RAM MR
> > acpi-build: make ROMs RAM blocks resizeable
> >
> > hw/lm32/lm32_hwsetup.h | 3 +-
> > include/exec/cpu-all.h | 12 +++--
> > include/exec/memory.h | 34 +++++++++++++
> > include/exec/ram_addr.h | 22 +++++++--
> > include/hw/loader.h | 4 +-
> > arch_init.c | 28 ++++++-----
> > exec.c | 129 +++++++++++++++++++++++++++++++++++++-----------
> > hw/core/loader.c | 18 +++++--
> > hw/i386/acpi-build.c | 19 +++++--
> > memory.c | 33 +++++++++++++
> > 10 files changed, 242 insertions(+), 60 deletions(-)
> >
> >
> >
>
> I don't think these are necessary, and I thought these were just RFC
> when they were posted. I and mst didn't really understand each other,
> and I take the fault for not reviewing the submission; however, Peter,
> please hold these for a little more.
>
> Paolo
Yes, please do, I'd like Paolo to review at least the memory core
changes.
--
MST
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [Qemu-devel] [PULL 0/8] pc: resizeable ROM blocks
2014-12-24 12:41 ` Michael S. Tsirkin
@ 2015-01-07 7:33 ` Paolo Bonzini
2015-01-07 10:03 ` Michael S. Tsirkin
2015-01-19 14:04 ` Igor Mammedov
0 siblings, 2 replies; 22+ messages in thread
From: Paolo Bonzini @ 2015-01-07 7:33 UTC (permalink / raw)
To: Michael S. Tsirkin
Cc: Peter Maydell, imammedo, qemu-devel, dgilbert, Juan Quintela
On 24/12/2014 13:41, Michael S. Tsirkin wrote:
>> I don't think these are necessary, and I thought these were just RFC
>> when they were posted. I and mst didn't really understand each other,
>> and I take the fault for not reviewing the submission; however, Peter,
>> please hold these for a little more.
>>
>> Paolo
>
> Yes, please do, I'd like Paolo to review at least the memory core
> changes.
I don't have any issue with the implementation; I'm just not sure that
this is necessary.
My point is that until ACPI tables are actually trimmed, migration
really won't be broken. So there is no need to apply these patches
until/unless we are ready to trim the tables.
Worst case, some scenarios can now print the "migration may not work"
warning if ACPI tables go from <64k to >64k. But migration actually
will work until the tables shoot beyond >128k.
The warning sucks, and the workaround we have (round to twice the
"expected" maximum size for "reasonable" VMs) is limited and hence also
sucks. But it _does_ work as a stopgap until we figure out what
migration of ACPI tables really entails.
The question then is: when should we trim the tables? Because answering
that question also answers whether we should apply your patches. My
answer to that question is "not anytime soon", perhaps 2.4 but more
likely 2.5.
For 2.3, the target should be the two other pending ACPI series that
reorganize the tables. In different and complementary ways, both
attempt at making the tables more predictable and thus mitigate or
resolve the migration problems. My patches add some separation between
"mutable" and "constant" tables. Igor's patches make "constant" tables
really constant by taking IASL out of the equation. (Note that if
useful, the C generation can also be applied to the mutable tables; it's
also possible to have a mutable SSDT and a constant one, the only
requirement for mutable tables is that their size be bounded).
I cannot of course be sure of how the ACPI tables will evolve in the
future. But we can give a try to the improvements that I and Igor
introduced for a release cycle or two. For those releases we can still
keep the 128k ACPI tables, and detect breakage using bios-tables-test.
We can improve the test to check table sizes (not contents) for a bunch
of configurations. We only need to cover edges, not paths, so it's not
hard to do.
Paolo
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [Qemu-devel] [PULL 0/8] pc: resizeable ROM blocks
2015-01-07 7:33 ` Paolo Bonzini
@ 2015-01-07 10:03 ` Michael S. Tsirkin
2015-01-07 10:52 ` Paolo Bonzini
2015-01-19 14:04 ` Igor Mammedov
1 sibling, 1 reply; 22+ messages in thread
From: Michael S. Tsirkin @ 2015-01-07 10:03 UTC (permalink / raw)
To: Paolo Bonzini
Cc: Peter Maydell, imammedo, qemu-devel, dgilbert, Juan Quintela
On Wed, Jan 07, 2015 at 08:33:07AM +0100, Paolo Bonzini wrote:
>
>
> On 24/12/2014 13:41, Michael S. Tsirkin wrote:
> >> I don't think these are necessary, and I thought these were just RFC
> >> when they were posted. I and mst didn't really understand each other,
> >> and I take the fault for not reviewing the submission; however, Peter,
> >> please hold these for a little more.
> >>
> >> Paolo
> >
> > Yes, please do, I'd like Paolo to review at least the memory core
> > changes.
>
> I don't have any issue with the implementation; I'm just not sure that
> this is necessary.
>
> My point is that until ACPI tables are actually trimmed, migration
> really won't be broken. So there is no need to apply these patches
> until/unless we are ready to trim the tables.
So far, the only case where we *didn't* break migration was when
we only did minor changes, in 2.2.
So sorry, I don't buy the "reviewed the code and it's safe" argument.
There's just too much state. Assume there will be bugs. What is a
solution you propose to make at least one way migration work in case of
bugs?
Without answering this question, I don't see how we can make
major changes in the subsystem.
I guess this boils down to this: what's the risk associated with
merging this patchset? It's a small amount of code.
--
MST
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [Qemu-devel] [PULL 0/8] pc: resizeable ROM blocks
2015-01-07 10:03 ` Michael S. Tsirkin
@ 2015-01-07 10:52 ` Paolo Bonzini
2015-01-07 12:37 ` Michael S. Tsirkin
0 siblings, 1 reply; 22+ messages in thread
From: Paolo Bonzini @ 2015-01-07 10:52 UTC (permalink / raw)
To: Michael S. Tsirkin
Cc: Peter Maydell, imammedo, qemu-devel, dgilbert, Juan Quintela
On 07/01/2015 11:03, Michael S. Tsirkin wrote:
> On Wed, Jan 07, 2015 at 08:33:07AM +0100, Paolo Bonzini wrote:
>>
>>
>> On 24/12/2014 13:41, Michael S. Tsirkin wrote:
>>>> I don't think these are necessary, and I thought these were just RFC
>>>> when they were posted. I and mst didn't really understand each other,
>>>> and I take the fault for not reviewing the submission; however, Peter,
>>>> please hold these for a little more.
>>>>
>>>> Paolo
>>>
>>> Yes, please do, I'd like Paolo to review at least the memory core
>>> changes.
>>
>> I don't have any issue with the implementation; I'm just not sure that
>> this is necessary.
>>
>> My point is that until ACPI tables are actually trimmed, migration
>> really won't be broken. So there is no need to apply these patches
>> until/unless we are ready to trim the tables.
>
> So far, the only case where we *didn't* break migration was when
> we only did minor changes, in 2.2.
Until 2.1 the code wasn't even trying to support migration (the rounding
to 4K was there for that reason, but it just distracted us from the real
issues), so I don't think releases before 2.1 count.
And I would say that it's not designed to support migration now, either.
It's just bypassing the problem.
Once you _do_ have a design that includes migration, things fall into
place much more nicely. That's where we are now with devices, and where
my+Igor's patches should bring us for ACPI. You can still screw up, of
course. But my preferred way to do "defense in depth" is not to have a
safety valve and scream after it triggers. It's to make the job easier
for us all:
1) have unit tests so that if you screw up existing code, "make check"
barfs for the developer;
2) enforce new unit tests with new code, to simplify the reviewer's job.
> So sorry, I don't buy the "reviewed the code and it's safe" argument.
> There's just too much state. Assume there will be bugs. What is a
> solution you propose to make at least one way migration work in case of
> bugs?
Design so that the tables are extensible and bugs are detected before
the code is committed (my stuff). Make the code easier to review, trim
external factors such as IASL version, avoid wheels being reinvented
(Igor's).
Maybe it's too optimistic. That's why I'm saying do not trim the tables
for a couple releases more.
If you have a bug, you're changing guest ABI. We're focusing on
migration, but it is just the tip of the iceberg.
Paolo
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [Qemu-devel] [PULL 0/8] pc: resizeable ROM blocks
2015-01-07 10:52 ` Paolo Bonzini
@ 2015-01-07 12:37 ` Michael S. Tsirkin
2015-01-07 12:59 ` Paolo Bonzini
0 siblings, 1 reply; 22+ messages in thread
From: Michael S. Tsirkin @ 2015-01-07 12:37 UTC (permalink / raw)
To: Paolo Bonzini
Cc: Peter Maydell, imammedo, qemu-devel, dgilbert, Juan Quintela
On Wed, Jan 07, 2015 at 11:52:40AM +0100, Paolo Bonzini wrote:
> Maybe it's too optimistic. That's why I'm saying do not trim the tables
> for a couple releases more.
I think it is too optimistic, and not trimming the tables does not
solve it convincingly enough to my taste.
> If you have a bug, you're changing guest ABI.
That's not how we designed it. ACPI tables are just generated firmware.
They are *not* ABI.
> We're focusing on
> migration, but it is just the tip of the iceberg.
In fact, I think that's the only issue.
Snapshoting firmware at each release is not something
we can support.
--
MST
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [Qemu-devel] [PULL 0/8] pc: resizeable ROM blocks
2015-01-07 12:37 ` Michael S. Tsirkin
@ 2015-01-07 12:59 ` Paolo Bonzini
0 siblings, 0 replies; 22+ messages in thread
From: Paolo Bonzini @ 2015-01-07 12:59 UTC (permalink / raw)
To: Michael S. Tsirkin
Cc: Peter Maydell, imammedo, qemu-devel, dgilbert, Juan Quintela
On 07/01/2015 13:37, Michael S. Tsirkin wrote:
> On Wed, Jan 07, 2015 at 11:52:40AM +0100, Paolo Bonzini wrote:
>> Maybe it's too optimistic. That's why I'm saying do not trim the tables
>> for a couple releases more.
>
> I think it is too optimistic, and not trimming the tables does not
> solve it convincingly enough to my taste.
Not trimming the tables is just to give us more time to think about
problems with the new world order that Igor and I are introducing. I
don't want to rush it.
I'm okay with merging the patches together with the trimming, if the
experience during this time tells us that I was too optimistic.
>> If you have a bug, you're changing guest ABI.
>
> That's not how we designed it. ACPI tables are just generated firmware.
> They are *not* ABI.
They are the only part of the firmware that a) describes the machine and
b) runs inside the OS. So they are at least special.
Paolo
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [Qemu-devel] [PULL 0/8] pc: resizeable ROM blocks
2015-01-07 7:33 ` Paolo Bonzini
2015-01-07 10:03 ` Michael S. Tsirkin
@ 2015-01-19 14:04 ` Igor Mammedov
1 sibling, 0 replies; 22+ messages in thread
From: Igor Mammedov @ 2015-01-19 14:04 UTC (permalink / raw)
To: Paolo Bonzini
Cc: Peter Maydell, Juan Quintela, qemu-devel, dgilbert,
Michael S. Tsirkin
On Wed, 07 Jan 2015 08:33:07 +0100
Paolo Bonzini <pbonzini@redhat.com> wrote:
>
>
> On 24/12/2014 13:41, Michael S. Tsirkin wrote:
> >> I don't think these are necessary, and I thought these were just RFC
> >> when they were posted. I and mst didn't really understand each other,
> >> and I take the fault for not reviewing the submission; however, Peter,
> >> please hold these for a little more.
> >>
> >> Paolo
> >
> > Yes, please do, I'd like Paolo to review at least the memory core
> > changes.
>
> I don't have any issue with the implementation; I'm just not sure that
> this is necessary.
>
> My point is that until ACPI tables are actually trimmed, migration
> really won't be broken. So there is no need to apply these patches
> until/unless we are ready to trim the tables.
My ACPI patches, mainly do not include any trimming due to the fact that
it will break current migration (i.e. blob size conditions will change
and break currently working setups). With this series we could trim
not present devices descriptions from ACPI tables reducing its size
safely (wrt migration). IMHO this series should be in tree before any
trimming is implemented and the sooner the better (i.e. we would be able
do forward/backward migration to/from 2.3(with theses patches) to/from
newer versions with trimmed tables).
I'm in favor of this series approach as it let us take care of ACPI tables
migration once and don't care about it anymore VS Paolo's byte-by-byte
compatible SSDT for each machine type whenever we change/fix ACPI tables.
>
> Paolo
>
^ permalink raw reply [flat|nested] 22+ messages in thread