[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [PULL 0/8] pc: resizeable ROM blocks
From: |
Michael S. Tsirkin |
Subject: |
Re: [Qemu-devel] [PULL 0/8] pc: resizeable ROM blocks |
Date: |
Wed, 7 Jan 2015 12:03:13 +0200 |
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.
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?
Without answering this question, I don't see how we can make
major changes in the subsystem.
I guess this boils down to this: what's the risk associated with
merging this patchset? It's a small amount of code.
--
MST