Re: [Qemu-devel] [PULL 0/8] pc: resizeable ROM blocks

[Paolo Bonzini]

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