qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH 0/6] pc: bring ACPI table size below to 2.0 leve


From: Paolo Bonzini
Subject: Re: [Qemu-devel] [PATCH 0/6] pc: bring ACPI table size below to 2.0 levels, try fixing -initrd for good
Date: Mon, 06 Oct 2014 15:42:01 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.1.1

Il 02/10/2014 15:49, Michael S. Tsirkin ha scritto:
>>> The issue is that incoming migration might have a different
>>> fw_cfg size from what we have.
>>
>> Understood now.
>>
>>> I think migrating this value will solve the issue in a cleaner way.
>>
>> Perhaps.  The question is whether it would complicate the
>> forwards-migration code beyond what is sane.  I think we are practically
>> speaking stuck with RAM.
> 
> Migrating RAM size is actually useful too, I think someone asked for it.

Migrating RAM size was discussed for BIOS and option ROMs, in order to
support migration from old versions of QEMU.  It was floated around for
some time, but ultimately we ended up shipping two copies of affected
firmware (128k/256k BIOS, and non-EFI/EFI option ROMs).

For BIOS it wouldn't be enough, because the BIOS size affects the memory
map.  Of course ACPI tables aren't mapped anywhere, but I'd be wary of
adding code to migration that is half-broken and almost never used.

Also, RAM blocks that have different size would be yet another thing
that makes machine types "almost compatible" with the QEMU version
they're supposed to represent.  In a scenario similar to John's, with
mutable RAM sizes, would have likely broken all machine types, because
we would not have bothered doing full backwards-compatibility.

I'm not an advocate of backwards bug-compatibility, but I think RAM
block sizes are way beyond the line of what we should be allowed to
modify between machine types.

Paolo



reply via email to

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