[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [PATCH 0/6] pc: bring ACPI table size below to 2.0 leve
From: |
Michael S. Tsirkin |
Subject: |
Re: [Qemu-devel] [PATCH 0/6] pc: bring ACPI table size below to 2.0 levels, try fixing -initrd for good |
Date: |
Mon, 6 Oct 2014 16:52:53 +0300 |
On Mon, Oct 06, 2014 at 03:42:01PM +0200, Paolo Bonzini wrote:
> Il 02/10/2014 15:49, Michael S. Tsirkin ha scritto:
> >>> The issue is that incoming migration might have a different
> >>> fw_cfg size from what we have.
> >>
> >> Understood now.
> >>
> >>> I think migrating this value will solve the issue in a cleaner way.
> >>
> >> Perhaps. The question is whether it would complicate the
> >> forwards-migration code beyond what is sane. I think we are practically
> >> speaking stuck with RAM.
> >
> > Migrating RAM size is actually useful too, I think someone asked for it.
>
> Migrating RAM size was discussed for BIOS and option ROMs, in order to
> support migration from old versions of QEMU. It was floated around for
> some time, but ultimately we ended up shipping two copies of affected
> firmware (128k/256k BIOS, and non-EFI/EFI option ROMs).
>
> For BIOS it wouldn't be enough, because the BIOS size affects the memory
> map. Of course ACPI tables aren't mapped anywhere, but I'd be wary of
> adding code to migration that is half-broken and almost never used.
>
> Also, RAM blocks that have different size would be yet another thing
> that makes machine types "almost compatible" with the QEMU version
> they're supposed to represent. In a scenario similar to John's, with
> mutable RAM sizes, would have likely broken all machine types, because
> we would not have bothered doing full backwards-compatibility.
>
> I'm not an advocate of backwards bug-compatibility, but I think RAM
> block sizes are way beyond the line of what we should be allowed to
> modify between machine types.
>
> Paolo
Maybe we should just modify ACPI and rom files in general to use
something else, not RAM?
It looked like a good fit initially so we went ahead with it,
but these things are fairly small, so it's not a problem to
migrate them as part of the device state.
--
MST
- Re: [Qemu-devel] [PATCH 0/6] pc: bring ACPI table size below to 2.0 levels, try fixing -initrd for good, Michael S. Tsirkin, 2014/10/02
- Re: [Qemu-devel] [PATCH 0/6] pc: bring ACPI table size below to 2.0 levels, try fixing -initrd for good, Paolo Bonzini, 2014/10/02
- Re: [Qemu-devel] [PATCH 0/6] pc: bring ACPI table size below to 2.0 levels, try fixing -initrd for good, Paolo Bonzini, 2014/10/02
- Re: [Qemu-devel] [PATCH 0/6] pc: bring ACPI table size below to 2.0 levels, try fixing -initrd for good, Michael S. Tsirkin, 2014/10/02
- Re: [Qemu-devel] [PATCH 0/6] pc: bring ACPI table size below to 2.0 levels, try fixing -initrd for good, Paolo Bonzini, 2014/10/02
- Re: [Qemu-devel] [PATCH 0/6] pc: bring ACPI table size below to 2.0 levels, try fixing -initrd for good, Michael S. Tsirkin, 2014/10/02
- Re: [Qemu-devel] [PATCH 0/6] pc: bring ACPI table size below to 2.0 levels, try fixing -initrd for good, Paolo Bonzini, 2014/10/06
- Re: [Qemu-devel] [PATCH 0/6] pc: bring ACPI table size below to 2.0 levels, try fixing -initrd for good,
Michael S. Tsirkin <=
- Re: [Qemu-devel] [PATCH 0/6] pc: bring ACPI table size below to 2.0 levels, try fixing -initrd for good, Paolo Bonzini, 2014/10/06
- Re: [Qemu-devel] [PATCH 0/6] pc: bring ACPI table size below to 2.0 levels, try fixing -initrd for good, Michael S. Tsirkin, 2014/10/06