[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [PATCH 2/5] exec: qemu_ram_alloc_device, qemu_ram_resiz
From: |
Paolo Bonzini |
Subject: |
Re: [Qemu-devel] [PATCH 2/5] exec: qemu_ram_alloc_device, qemu_ram_resize |
Date: |
Tue, 18 Nov 2014 07:03:58 +0100 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 |
On 17/11/2014 21:08, Michael S. Tsirkin wrote:
> Add API to manage on-device RAM.
> This looks just like regular RAM from migration POV,
> but has two special properties internally:
>
> - block is sized on migration, making it easier to extend
> without breaking migration compatibility or wasting
> virtual memory
> - callers must specify an upper bound on size
Why should on-device RAM have this property, or why should this property
be interesting for on-device RAM (as opposed to generic "we are using
MemoryRegions internally and we want them resized")?
I admit the patches look clean, but I would prefer to have some changes
to the API and I dislike introducing a worse API just because we are so
close to release. For example, the resized callback should probably
receive a MemoryRegion, not a host/length pair, or even better there
could be a NotifierList per RAMBlock.
Also, I am afraid that this design could make it easier to introduce
backwards-incompatible changes. I very much prefer to have
user-controlled ACPI information (coming from the command-line)
byte-for-byte identical for a given machine type. Patches for that have
been on the list for almost two months, and it's not nice.
Paolo
- [Qemu-devel] [PATCH 0/5] pc: make ROMs resizeable, Michael S. Tsirkin, 2014/11/17
- [Qemu-devel] [PATCH 1/5] cpu: add cpu_physical_memory_clear_dirty_range_nocode, Michael S. Tsirkin, 2014/11/17
- [Qemu-devel] [PATCH 2/5] exec: qemu_ram_alloc_device, qemu_ram_resize, Michael S. Tsirkin, 2014/11/17
- Re: [Qemu-devel] [PATCH 2/5] exec: qemu_ram_alloc_device, qemu_ram_resize, Michael S. Tsirkin, 2014/11/17
- Re: [Qemu-devel] [PATCH 2/5] exec: qemu_ram_alloc_device, qemu_ram_resize,
Paolo Bonzini <=
- Re: [Qemu-devel] [PATCH 2/5] exec: qemu_ram_alloc_device, qemu_ram_resize, Michael S. Tsirkin, 2014/11/18
- Re: [Qemu-devel] [PATCH 2/5] exec: qemu_ram_alloc_device, qemu_ram_resize, Juan Quintela, 2014/11/19
- Re: [Qemu-devel] [PATCH 2/5] exec: qemu_ram_alloc_device, qemu_ram_resize, Michael S. Tsirkin, 2014/11/19
- Re: [Qemu-devel] [PATCH 2/5] exec: qemu_ram_alloc_device, qemu_ram_resize, Juan Quintela, 2014/11/19
- Re: [Qemu-devel] [PATCH 2/5] exec: qemu_ram_alloc_device, qemu_ram_resize, Michael S. Tsirkin, 2014/11/19
- Re: [Qemu-devel] [PATCH 2/5] exec: qemu_ram_alloc_device, qemu_ram_resize, Juan Quintela, 2014/11/19
- Re: [Qemu-devel] [PATCH 2/5] exec: qemu_ram_alloc_device, qemu_ram_resize, Michael S. Tsirkin, 2014/11/19
- Re: [Qemu-devel] [PATCH 2/5] exec: qemu_ram_alloc_device, qemu_ram_resize, Paolo Bonzini, 2014/11/19
- Re: [Qemu-devel] [PATCH 2/5] exec: qemu_ram_alloc_device, qemu_ram_resize, Juan Quintela, 2014/11/19
- Re: [Qemu-devel] [PATCH 2/5] exec: qemu_ram_alloc_device, qemu_ram_resize, Dr. David Alan Gilbert, 2014/11/19