[Qemu-devel] RFC: Qemu/SeaBIOS/VGA/PXE upgrades vs. longterm-snapshot/migration

[Qemu-devel] RFC: Qemu/SeaBIOS/VGA/PXE upgrades vs. longterm-snapshot/migration

[Philipp Hahn]

Hello,

If my understanding of migration/snapshots is correct, the
target/loading VM must be a clone of the source/saving VM, that is have
the same devices, RAM/PCI layout, etc. In the past I have had several
issues with Qemu, when the distribution (Debian) updates their packaging
of SeaBIOS/iPXE/VgaROM, which changes the the next/previous power-of-2
size and thus changes the PCI layout, preventing me from loading old
snapshots.

As the BIOS file is provided externally, it is prone to such
(accidental) updates. As (AFAIK) libvirt does not track the Qemu
version, BIOS files inside its XML data, there's always the danger of
making snapshots invalid by updating Qemu and the BIOS files.

Some questions:

1. Does Qemu use ROM shadowing, that is copying the ROM to RAM? This
makes sense on real HW as ROMs are a low slower than RAM. In that case
the content of the "ROM" would already be contained inside the VM-State
and it would be enough to provide an "empty ROM file of the right size".

2. If Qemu does no ROM shadowing, what happens if I suspend a VM while
executing ROM or SMM code and then doing an SeaBIOS update? (my
DOS-assembler knowledge is quiet old nowadays)

3. How do others handle long-term snapshots? Just say "good-bye" to your
old snapshots when upgrading to a newer Qemu version or keeping the old,
probably unmaintained and vulnerable Qemu/BIOS binaries until the
end-of-time?

Thanks in advance
Philipp
-- 
Philipp Hahn
Open Source Software Engineer

Univention GmbH
be open.
Mary-Somerville-Str. 1
D-28359 Bremen
Tel.: +49 421 22232-0
Fax : +49 421 22232-99
hahn@univention.de

http://www.univention.de/
Geschäftsführer: Peter H. Ganten
HRB 20755 Amtsgericht Bremen
Steuer-Nr.: 71-597-02876

Re: [Qemu-devel] RFC: Qemu/SeaBIOS/VGA/PXE upgrades vs. longterm-snapshot/migration

[Paolo Bonzini]

On 29/08/2016 08:57, Philipp Hahn wrote:
> Hello,
> 
> If my understanding of migration/snapshots is correct, the
> target/loading VM must be a clone of the source/saving VM, that is have
> the same devices, RAM/PCI layout, etc. In the past I have had several
> issues with Qemu, when the distribution (Debian) updates their packaging
> of SeaBIOS/iPXE/VgaROM, which changes the the next/previous power-of-2
> size and thus changes the PCI layout, preventing me from loading old
> snapshots.
> 
> As the BIOS file is provided externally, it is prone to such
> (accidental) updates. As (AFAIK) libvirt does not track the Qemu
> version, BIOS files inside its XML data, there's always the danger of
> making snapshots invalid by updating Qemu and the BIOS files.

Right.  For the BIOS we distribute two versions, one which stays under
128k and one which stays under 256k.

For iPXE we also distribute two versions.  The basic version has no UEFI
support is under 64k (under 128k for pxe-e1000.rom), the one with UEFI
support is under 256k.

VGA is always under 64k.

There is quite some leeway, but it's possible for distributions to screw
up.  One possibility would be to add "expected" sizes to QEMU and fail
to start if the files don't fit in the expected size.

> 1. Does Qemu use ROM shadowing, that is copying the ROM to RAM? This
> makes sense on real HW as ROMs are a low slower than RAM. In that case
> the content of the "ROM" would already be contained inside the VM-State
> and it would be enough to provide an "empty ROM file of the right size".

QEMU does ROM shadowing, but it's not enough to provide an empty ROM
file because the unshadowed ROM is available through BAR6.

> 2. If Qemu does no ROM shadowing, what happens if I suspend a VM while
> executing ROM or SMM code and then doing an SeaBIOS update? (my
> DOS-assembler knowledge is quiet old nowadays)

Even though QEMU does do ROM shadowing, this is a good question.  The
contents of the ROM are migrated from the source to the destination, so
the destination sees exactly the same contents.

This means that an old BIOS might run on a new QEMU.  Occasionally this
may cause bugs, but we try to test migration and detect them before the
release.

> 3. How do others handle long-term snapshots? Just say "good-bye" to your
> old snapshots when upgrading to a newer Qemu version or keeping the old,
> probably unmaintained and vulnerable Qemu/BIOS binaries until the
> end-of-time?

It's up to the distros to ensure that compatibility ROM files (bios.bin
and pxe-*.rom) have the right size (128k for bios.bin and pxe-e1000.rom,
64k for the others).  If they don't, complain.

You can have the right size even if you compile from newer sources, thus
any vulnerabilities get fixed the next time you start the VM with a
fresh QEMU installation.

Paolo