From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:43200) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VIyAI-0003JJ-JF for qemu-devel@nongnu.org; Mon, 09 Sep 2013 05:53:59 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VIyAA-0000Od-5Y for qemu-devel@nongnu.org; Mon, 09 Sep 2013 05:53:50 -0400 Received: from mail-ea0-x231.google.com ([2a00:1450:4013:c01::231]:55076) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VIyA9-0000OQ-UH for qemu-devel@nongnu.org; Mon, 09 Sep 2013 05:53:42 -0400 Received: by mail-ea0-f177.google.com with SMTP id f15so2983678eak.22 for ; Mon, 09 Sep 2013 02:53:41 -0700 (PDT) Sender: Paolo Bonzini Message-ID: <522D9AA9.6060303@redhat.com> Date: Mon, 09 Sep 2013 11:53:45 +0200 From: Paolo Bonzini MIME-Version: 1.0 References: <1378386382-415-1-git-send-email-pbonzini@redhat.com> <1378386382-415-2-git-send-email-pbonzini@redhat.com> <20130908114044.GF17294@redhat.com> <522D8753.7010009@redhat.com> <20130909090315.GM17294@redhat.com> In-Reply-To: <20130909090315.GM17294@redhat.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH uq/master 1/2] x86: fix migration from pre-version 12 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Gleb Natapov Cc: qemu-devel@nongnu.org, kvm@vger.kernel.org, ehabkost@redhat.com Il 09/09/2013 11:03, Gleb Natapov ha scritto: > On Mon, Sep 09, 2013 at 10:31:15AM +0200, Paolo Bonzini wrote: >> Il 08/09/2013 13:40, Gleb Natapov ha scritto: >>> On Thu, Sep 05, 2013 at 03:06:21PM +0200, Paolo Bonzini wrote: >>>> On KVM, the KVM_SET_XSAVE would be executed with a 0 xstate_bv, >>>> and not restore anything. >>>> >>> XRSTOR restores FP/SSE state to reset state if no bits are set in >>> xstate_bv. This is what should happen on reset, no? >> >> Yes. The problem happens on the migration destination when XSAVE data is >> not transmitted. FP/SSE data is transmitted and must be restored, but >> xstate_bv is zero and KVM_SET_XSAVE restores FP/SSE state to reset >> state. The vcpu then loses the values that were set in the migration data. >> >>>> Since FP and SSE data are always valid, set them in xstate_bv at reset >>>> time. In fact, that value is the same that KVM_GET_XSAVE returns on >>>> pre-XSAVE hosts. >>> It is needed for migration between non xsave host to xsave host. >> >> Yes, and this patch does the same for migration between non-XSAVE QEMU >> and XSAVE QEMU. >> > Can such migration happen? The commit that added xsave support > (f1665b21f16c5dc0ac37de60233a4975aff31193) changed vmstate version id. Yes, old->new migration can happen. New->old of course cannot. >> In fact, another bug is that kvm_vcpu_ioctl_x86_set_xsave ignores >> xstate_bv when XSAVE is not available. Instead, it should reset the >> FXSAVE data to processor-reset values (except for MXCSR which always >> comes from XRSTOR data), i.e. to all-zeros except for the x87 control >> and tag words. It should also check reserved bits of MXCSR. > > I do not see why. Because otherwise it behaves in a subtly different manner for XSAVE and non-XSAVE hosts. >> Yes. QEMU unmarshals information from the XSAVE region and back, so it >> cannot support MPX or AVX-512 yet (even if KVM were). Separate bug, though. >> > IMO this is the main issue here, not separate bug. If we gonna let guest > use CPU state QEMU does not support we gonna have a bad time. We cannot force the guest not to use a feature; all we can do is hide the CPUID bits so that a well-behaved guest will not use it. QEMU does hide CPUID bits for non-supported XSAVE states, except for "-cpu host". So this will not be a problem except with "-cpu host". Paolo