On 2011-06-14 10:23, Avi Kivity wrote: > On 06/14/2011 09:10 AM, Jan Kiszka wrote: >> On 2011-06-13 10:45, Avi Kivity wrote: >> > On 06/11/2011 12:23 PM, Jan Kiszka wrote: >> >> From: Jan Kiszka<jan.kis...@siemens.com> >> >> >> >> These FPU states are properly maintained by KVM but not yet by >> TCG. So >> >> far we unconditionally set them to 0 in the guest which may cause >> >> state corruptions - not only during migration. >> >> >> >> >> >> -#define CPU_SAVE_VERSION 12 >> >> +#define CPU_SAVE_VERSION 13 >> >> >> > >> > Incrementing the version number seems excessive - I can't imagine a >> > real-life guest will break due to fp pointer corruption >> > >> > However, I don't think we have a mechanism for optional state. We >> > discussed this during the 18th VMState Subsection Symposium and IIRC >> > agreed to re-raise the issue when we encountered it, which appears >> to be >> > now. >> > >> >> Whatever we invent, it has to be backported as well to allow that >> infamous traveling back in time, migrating VMs from newer to older >> versions. >> >> Would that backporting be simpler if we used an unconditional subsection >> for the additional states? > > Most likely. It depends on what mechanism we use. > > Let's spend some time to think about what it would be like. This patch > is not urgent, is it? (i.e. it was discovered by code inspection, not > live migration that caught the cpu between an instruction that caused a > math exception and the exception handler).
Right, not urgent, should just make it into 0.15 in the end. Jan
signature.asc
Description: OpenPGP digital signature
