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: Igor Mammedov
Subject: Re: [Qemu-devel] [PULL 0/8] pc: resizeable ROM blocks
Date: Mon, 19 Jan 2015 15:04:38 +0100

On Wed, 07 Jan 2015 08:33:07 +0100
Paolo Bonzini <address@hidden> 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.

My ACPI patches, mainly do not include any trimming due to the fact that
it will break current migration (i.e. blob size conditions will change
and break currently working setups). With this series we could trim
not present devices descriptions from ACPI tables reducing its size
safely (wrt migration). IMHO this series should be in tree before any
trimming is implemented and the sooner the better (i.e. we would be able
do forward/backward migration to/from 2.3(with theses patches) to/from
newer versions with trimmed tables).

I'm in favor of this series approach as it let us take care of ACPI tables
migration once and don't care about it anymore VS Paolo's byte-by-byte
compatible SSDT for each machine type whenever we change/fix ACPI tables.

> 
> Paolo
> 




reply via email to

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