qemu-devel
[Top][All Lists]
Advanced

[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



reply via email to

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