qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Jan Kiszka <jan.kiszka@web.de>
To: Avi Kivity <avi@redhat.com>
Cc: Christophe Fergeau <cfergeau@redhat.com>,
	Marcelo Tosatti <mtosatti@redhat.com>,
	qemu-devel <qemu-devel@nongnu.org>, kvm <kvm@vger.kernel.org>,
	Stefan Hajnoczi <stefanha@linux.vnet.ibm.com>
Subject: Re: [Qemu-devel] [PATCH][uq/master] kvm: x86: Save/restore FPU OP, IP and DP
Date: Tue, 14 Jun 2011 08:10:42 +0200	[thread overview]
Message-ID: <4DF6FB62.60705@web.de> (raw)
In-Reply-To: <4DF5CE2E.50008@redhat.com>

[-- Attachment #1: Type: text/plain, Size: 1036 bytes --]

On 2011-06-13 10:45, Avi Kivity wrote:
> On 06/11/2011 12:23 PM, Jan Kiszka wrote:
>> From: Jan Kiszka<jan.kiszka@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?

Jan


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 259 bytes --]

  reply	other threads:[~2011-06-14  6:10 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-06-11  9:23 [Qemu-devel] [PATCH][uq/master] kvm: x86: Save/restore FPU OP, IP and DP Jan Kiszka
2011-06-13  8:45 ` Avi Kivity
2011-06-14  6:10   ` Jan Kiszka [this message]
2011-06-14  8:23     ` Avi Kivity
2011-06-14  8:28       ` Jan Kiszka
2011-06-15  9:10     ` Avi Kivity
2011-06-15 10:20       ` Jan Kiszka
2011-06-15 10:39         ` Jan Kiszka
2011-06-15 11:26         ` Avi Kivity
2011-06-15 11:32           ` Jan Kiszka
2011-06-15 11:33             ` Avi Kivity
2011-06-15 11:45               ` Jan Kiszka
2011-06-15 13:17 ` [Qemu-devel] [PATCH v2][uq/master] " Jan Kiszka
2011-06-16  9:42   ` Christophe Fergeau
2011-06-19 12:58   ` Avi Kivity
2011-06-16  9:35 ` [Qemu-devel] [PATCH][uq/master] " Christophe Fergeau

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4DF6FB62.60705@web.de \
    --to=jan.kiszka@web.de \
    --cc=avi@redhat.com \
    --cc=cfergeau@redhat.com \
    --cc=kvm@vger.kernel.org \
    --cc=mtosatti@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=stefanha@linux.vnet.ibm.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).