qemu-devel
[Top][All Lists]
Advanced

[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: Juan Quintela
Subject: Re: [Qemu-devel] [PATCH 2/5] exec: qemu_ram_alloc_device, qemu_ram_resize
Date: Wed, 19 Nov 2014 17:50:55 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.4 (gnu/linux)

Paolo Bonzini <address@hidden> wrote:
> On 19/11/2014 15:10, Peter Maydell wrote:

> It does already, for example PPC uses it for its IOMMU tables.
>
> But in any case this is really just memory that is auto-resized on
> migration.  And it can work even if it is mapped in memory, as long as
> your resize callback (or some post_load code executed while migrating
> devices) does something useful to update the memory map.  Let's call it
> like what it is.
>
> Basically it is an "I know how to deal with the source's configuration
> whatever it is, so I'm not bothering to reconstruct it equivalently on
> the destination" flag.
>
> The fine print is that it will create more differences between a given
> machine type on different versions of QEMU.  It can have ripple effects
> on the memory map and it can make existing VMs a bit more likely to
> break when updating QEMU.  This is why I do not particularly like it,
> and I posted different patches to do the same thing.  I understand that
> it is a simple fix that will mostly work and probably avoids work more
> than causing it.
>
> And BTW, those patches are still unreviewed,.  Juan, "do as you
> preach"---review patches that are closer to what you preach.  And
> Michael, you too---review patches in addition to asking people to review
> yours, so that we can compare the approaches.

I will review them, for the migration bits.  But my ACPI knowledge is
basically: when I see ACPI, I run in the other direction O:-) (*)

Later, Juan.

(*) I think that this is all that is needed to know about ACPI O:-)



reply via email to

[Prev in Thread] Current Thread [Next in Thread]