Re: [Qemu-devel] [PATCH 2/5] exec: qemu_ram_alloc_device, qemu_ram_resize

["Michael S. Tsirkin" <mst@redhat.com>]

On Tue, Nov 18, 2014 at 07:03:58AM +0100, Paolo Bonzini wrote:
> 
> 
> 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 guess it's just a question of terminology.
internally == on device

> 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.

Well, please list the issues - maybe they are easy to resolve
even 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.

I will do that quickly, that's easy.
Any more changes?

> Also, I am afraid that this design could make it easier to introduce
> backwards-incompatible changes.


Well the point is exactly to make it easy to make *compatible*
changes.

As I mentioned in the cover letter, it's not just ACPI.
For example, we now change boot index dynamically.
People using large fw cfg blobs, e.g. -initrd, would benefit from
ability to change the blob dynamically.
There could be other examples.

>  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

I guess we just disagree on whether these patches will effectively achieve
this goal.  For example, some people want to rewrite iasl bits,
generating everything in C. This will affect static bits too.
I don't want to make every single change in code conditional
on a machine type.

-- 
MST