[Qemu-devel] Re: [SeaBIOS] [PATCH 0/8] option rom loadingoverhaul.
On 12/22/2009 01:58 AM, Gleb Natapov wrote: Your cable TV provider does likely also control what beside the FW (if anything) runs on your set-top-box. So he can verify the FW upgrade doesn't break anything in the field. That pre-deployment verification is not possible in non closed environments. Yet it doesn't stop HW manufacturers to require FW update as the first step of their support procedure. They don't do it automatically only because they can't. Let's put correctness aside for a moment. Right now, if you replace the contents of pc-bios while you have a guest running, heck, even if you rm -rf, the guest will continue functioning until you do a hard power off. Changing this behavior feels like a regression to me. It really seems to me like it makes things a lot more brittle. The only benefit I can see is that you'll use a new rom after migration after the first reset. Maybe that's desirable behavior although I'm not sure. I'd feel a lot better about something that read the real rom contents at start-up, and then replaced migrated roms after reset or something like that. That gives us the use-case without making qemu depend on rereading things while it's running. Regards, Anthony Liguori
[Qemu-devel] Re: [SeaBIOS] [PATCH 0/8] option rom loadingoverhaul.
On 12/21/2009 12:24 PM, Sebastian Herbszt wrote: As stated before i don't like the idea of automagically upgrading the firmware on reset, e.g. after a live migration to a newer qemu version. You have explained that qemu-kvm needs this in order to work with live migration and changed hw support because of bug fixes. Is this only needed in the kvm case? It's not needed, it's desired. The same case can be made for real hardware (automated firmware updates). Does any OS (Windows?) depend on the tables the bios creates (e.g. smbios) for licensing? It would be ugly if Windows wants you to re-activate after a reboot following a migration to newer qemu version and therefore possibly changed tables due to newer bios. Yes, and this is a good point. ACPI table changes can absolutely cause re-activation. If we migrate from 0.12 - 0.13 and make major changes to the ACPI tables in 0.13, then it's very likely that will result in problems for Windows guests. I really think that we need to snapshot the FW and store it with the guest state. If we switch all FW to be allocated with qemu_ram_alloc() and we use an id mechanism, then this will Just Work for savevm based snapshots and live migration. However, for it to work with -M pc-0.11 started from a cold boot, we need an nvram file. We probably want to make available versioned nvram files from each release too. Regards, Anthony Liguori - Sebastian
[Qemu-devel] Re: [SeaBIOS] [PATCH 0/8] option rom loadingoverhaul.
Anthony Liguori wrote: On 12/21/2009 12:24 PM, Sebastian Herbszt wrote: As stated before i don't like the idea of automagically upgrading the firmware on reset, e.g. after a live migration to a newer qemu version. You have explained that qemu-kvm needs this in order to work with live migration and changed hw support because of bug fixes. Is this only needed in the kvm case? It's not needed, it's desired. The same case can be made for real hardware (automated firmware updates). Tho on real hardware those updates are initiated by someone and not automagic. Does any OS (Windows?) depend on the tables the bios creates (e.g. smbios) for licensing? It would be ugly if Windows wants you to re-activate after a reboot following a migration to newer qemu version and therefore possibly changed tables due to newer bios. Yes, and this is a good point. ACPI table changes can absolutely cause re-activation. If we migrate from 0.12 - 0.13 and make major changes to the ACPI tables in 0.13, then it's very likely that will result in problems for Windows guests. Another problem could be on guest resume from S3 after migration if the bios or acpi tables change. I really think that we need to snapshot the FW and store it with the guest state. If we switch all FW to be allocated with qemu_ram_alloc() and we use an id mechanism, then this will Just Work for savevm based snapshots and live migration. However, for it to work with -M pc-0.11 started from a cold boot, we need an nvram file. We probably want to make available versioned nvram files from each release too. So the idea is to store the bios/option roms in the guest state and read them from there on reset or power cycle? - Sebastian
[Qemu-devel] Re: [SeaBIOS] [PATCH 0/8] option rom loadingoverhaul.
On Mon, Dec 21, 2009 at 01:17:23PM -0600, Anthony Liguori wrote: Does any OS (Windows?) depend on the tables the bios creates (e.g. smbios) for licensing? It would be ugly if Windows wants you to re-activate after a reboot following a migration to newer qemu version and therefore possibly changed tables due to newer bios. Yes, and this is a good point. ACPI table changes can absolutely cause re-activation. If we migrate from 0.12 - 0.13 and make major changes to the ACPI tables in 0.13, then it's very likely that will result in problems for Windows guests. On the contrary. This is very unlikely. Otherwise BIOS upgrade would cause Windows reactivation. I really think that we need to snapshot the FW and store it with the guest state. If we switch all FW to be allocated with qemu_ram_alloc() and we use an id mechanism, then this will Just Work for savevm based snapshots and live migration. However, for it to work with -M pc-0.11 started from a cold boot, we need an nvram file. We probably want to make available versioned nvram files from each release too. Yes, firmware should be part of machine description. -- Gleb.
[Qemu-devel] Re: [SeaBIOS] [PATCH 0/8] option rom loadingoverhaul.
On Mon, Dec 21, 2009 at 08:39:03PM +0100, Sebastian Herbszt wrote: Anthony Liguori wrote: On 12/21/2009 12:24 PM, Sebastian Herbszt wrote: As stated before i don't like the idea of automagically upgrading the firmware on reset, e.g. after a live migration to a newer qemu version. You have explained that qemu-kvm needs this in order to work with live migration and changed hw support because of bug fixes. Is this only needed in the kvm case? It's not needed, it's desired. The same case can be made for real hardware (automated firmware updates). Tho on real hardware those updates are initiated by someone and not automagic. Because on real hardware it is impossible to do it differently may be? My cable TV provider upgrades FW on my set-top-box automatically. Does any OS (Windows?) depend on the tables the bios creates (e.g. smbios) for licensing? It would be ugly if Windows wants you to re-activate after a reboot following a migration to newer qemu version and therefore possibly changed tables due to newer bios. Yes, and this is a good point. ACPI table changes can absolutely cause re-activation. If we migrate from 0.12 - 0.13 and make major changes to the ACPI tables in 0.13, then it's very likely that will result in problems for Windows guests. Another problem could be on guest resume from S3 after migration if the bios or acpi tables change. On resume from S3 BIOS doesn't recreate ACPI tables. ACPI tables are not part of a BIOS image and in fact OS can reuse memory ACPI tables reside in. So such problem definitely does not exist. I really think that we need to snapshot the FW and store it with the guest state. If we switch all FW to be allocated with qemu_ram_alloc() and we use an id mechanism, then this will Just Work for savevm based snapshots and live migration. However, for it to work with -M pc-0.11 started from a cold boot, we need an nvram file. We probably want to make available versioned nvram files from each release too. So the idea is to store the bios/option roms in the guest state and read them from there on reset or power cycle? - Sebastian -- Gleb.
[Qemu-devel] Re: [SeaBIOS] [PATCH 0/8] option rom loadingoverhaul.
Gleb Natapov wrote: On Mon, Dec 21, 2009 at 08:39:03PM +0100, Sebastian Herbszt wrote: Anthony Liguori wrote: On 12/21/2009 12:24 PM, Sebastian Herbszt wrote: As stated before i don't like the idea of automagically upgrading the firmware on reset, e.g. after a live migration to a newer qemu version. You have explained that qemu-kvm needs this in order to work with live migration and changed hw support because of bug fixes. Is this only needed in the kvm case? It's not needed, it's desired. The same case can be made for real hardware (automated firmware updates). Tho on real hardware those updates are initiated by someone and not automagic. Because on real hardware it is impossible to do it differently may be? My cable TV provider upgrades FW on my set-top-box automatically. Your cable TV provider does likely also control what beside the FW (if anything) runs on your set-top-box. So he can verify the FW upgrade doesn't break anything in the field. That pre-deployment verification is not possible in non closed environments. Does any OS (Windows?) depend on the tables the bios creates (e.g. smbios) for licensing? It would be ugly if Windows wants you to re-activate after a reboot following a migration to newer qemu version and therefore possibly changed tables due to newer bios. Yes, and this is a good point. ACPI table changes can absolutely cause re-activation. If we migrate from 0.12 - 0.13 and make major changes to the ACPI tables in 0.13, then it's very likely that will result in problems for Windows guests. Another problem could be on guest resume from S3 after migration if the bios or acpi tables change. On resume from S3 BIOS doesn't recreate ACPI tables. ACPI tables are not part of a BIOS image and in fact OS can reuse memory ACPI tables reside in. So such problem definitely does not exist. If the OS recycles the whole memory which holds the ACPI tables i am not sure how the BIOS will find the firmware_waking_vector. Maybe the OS can only use the memory which holds the DSDT? Anyway, will the guest even resume from S3 if the hw changed on migration and the bios doesn't know how to init it? - Sebastian
[Qemu-devel] Re: [SeaBIOS] [PATCH 0/8] option rom loadingoverhaul.
On Mon, Dec 21, 2009 at 09:16:17PM +0100, Sebastian Herbszt wrote: Gleb Natapov wrote: On Mon, Dec 21, 2009 at 08:39:03PM +0100, Sebastian Herbszt wrote: Anthony Liguori wrote: On 12/21/2009 12:24 PM, Sebastian Herbszt wrote: As stated before i don't like the idea of automagically upgrading the firmware on reset, e.g. after a live migration to a newer qemu version. You have explained that qemu-kvm needs this in order to work with live migration and changed hw support because of bug fixes. Is this only needed in the kvm case? It's not needed, it's desired. The same case can be made for real hardware (automated firmware updates). Tho on real hardware those updates are initiated by someone and not automagic. Because on real hardware it is impossible to do it differently may be? My cable TV provider upgrades FW on my set-top-box automatically. Your cable TV provider does likely also control what beside the FW (if anything) runs on your set-top-box. So he can verify the FW upgrade doesn't break anything in the field. That pre-deployment verification is not possible in non closed environments. Yet it doesn't stop HW manufacturers to require FW update as the first step of their support procedure. They don't do it automatically only because they can't. Does any OS (Windows?) depend on the tables the bios creates (e.g. smbios) for licensing? It would be ugly if Windows wants you to re-activate after a reboot following a migration to newer qemu version and therefore possibly changed tables due to newer bios. Yes, and this is a good point. ACPI table changes can absolutely cause re-activation. If we migrate from 0.12 - 0.13 and make major changes to the ACPI tables in 0.13, then it's very likely that will result in problems for Windows guests. Another problem could be on guest resume from S3 after migration if the bios or acpi tables change. On resume from S3 BIOS doesn't recreate ACPI tables. ACPI tables are not part of a BIOS image and in fact OS can reuse memory ACPI tables reside in. So such problem definitely does not exist. If the OS recycles the whole memory which holds the ACPI tables i am not sure how the BIOS will find the firmware_waking_vector. Maybe the OS can only use the memory which holds the DSDT? OS can reuse memory marked as ACPI data in e820 map. BIOS can put firmware_waking_vector pointer into reserved memory or ACPI NVS Anyway, will the guest even resume from S3 if the hw changed on migration and the bios doesn't know how to init it? Probably not, so we need to use new BIOS that knows how to init HW. -- Gleb.
