[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
>