On 22/01/19 10:22, Stefano Garzarella wrote: > On Mon, Jan 21, 2019 at 07:33:32PM +0100, Paolo Bonzini wrote: >> On 21/01/19 18:36, Stefano Garzarella wrote: >>>> >>>> | On Tue, Jan 15, 2019 at 01:57:22PM -0500, Michael S. Tsirkin wrote: >>>> | > OK but this is guest visible so needs to be guarded by the >>>> | > new machine type. >>>> | >>>> | Aren't option ROMs treated like other firmware? i.e.: guest >>>> | visible, but copied during live migration and not considered part >>>> | of guest ABI. >>> I don't know the exact answer, but reading the wiki, I think Michael is >>> right! >>> (https://wiki.qemu.org/Features/Migration/Troubleshooting#ROMs) >>> >>> Maybe it is related for PVH feature in general, because if we try to >>> migrate to a QEMU version that doesn't support PVH I'm not sure what is >>> the behaviour. >> >> As far as I understand, QEMU would fail to migrate to the destination >> because the PVH option ROM doesn't have a corresponding RAMBlock. >> > > I tried to migrate from a QEMU with PVH support to a QEMU without PVH, > (both with the same pc-q35-4.0 machine) and the migration doesn't fail. > > The guest, after the migration, works well, but when I tried to reboot, > the guest stuck. > > The "info ramblock" on both QEMU produce the same output: > Block Name PSize Offset Used > Total > pc.ram 4 KiB 0x0000000000000000 0x0000000020000000 > 0x0000000020000000 > /rom@etc/acpi/tables 4 KiB 0x0000000020080000 0x0000000000020000 > 0x0000000000200000 > pc.bios 4 KiB 0x0000000020000000 0x0000000000040000 > 0x0000000000040000 > pc.rom 4 KiB 0x0000000020040000 0x0000000000020000 > 0x0000000000020000 > /rom@etc/table-loader 4 KiB 0x0000000020280000 0x0000000000001000 > 0x0000000000001000 > /rom@etc/acpi/rsdp 4 KiB 0x00000000202c0000 0x0000000000001000 > 0x0000000000001000 > > > The following patch solves the issue. (Thanks Michael!) > Should I send the v6 of series or this patch alone for the review?
Send the patch alone, but there's no need to introduce 4.1 since the feature will be included in 4.0. Paolo
