From: Gleb Natapov <gleb@redhat.com>
To: Paolo Bonzini <pbonzini@redhat.com>
Cc: qemu-devel@nongnu.org, kvm@vger.kernel.org, ehabkost@redhat.com
Subject: Re: [Qemu-devel] [PATCH uq/master 1/2] x86: fix migration from pre-version 12
Date: Mon, 9 Sep 2013 15:00:50 +0300 [thread overview]
Message-ID: <20130909120050.GA6866@redhat.com> (raw)
In-Reply-To: <522DB529.4000001@redhat.com>
On Mon, Sep 09, 2013 at 01:46:49PM +0200, Paolo Bonzini wrote:
> >>>>>> 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
> >>>
> >>> Of course we can't, this is correct for other features too, but this is
> >>> guest's problem.
> >>
> >> Ok, then we agree that QEMU doesn't have a problem? The XSAVE data will
> >
> > Which problem exactly. The problems I see is that 1. We do not support
> > MPX and AVX-512 (but this is probably not the problem you meant :)) 2. 0D
> > data is not consistent with features. Guest may not expect it and do stupid
> > things.
>
> It is not a problem to unmarshal information out of KVM_GET_XSAVE data
> (and back). If the guest does stupid things, it's a bug in an
> ill-behaving guest.
>
You know I am first in line to blame guest for everything :) (who needs
guests anyway) but in this case I didn't mean that guest does something
illegal. If we advertise support for some XSAVE state in 0D leaf guest
is in his right to make conclusions we may not expect from that. It may
check corespondent feature bit and crash if it is not present for
instance.
> On the other hand, I agree that passthrough of host 0xD data is bad and
> will fix it.
>
Thanks!
--
Gleb.
next prev parent reply other threads:[~2013-09-09 12:01 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-09-05 13:06 [Qemu-devel] [PATCH uq/master 0/2] KVM: issues with XSAVE support Paolo Bonzini
2013-09-05 13:06 ` [Qemu-devel] [PATCH uq/master 1/2] x86: fix migration from pre-version 12 Paolo Bonzini
2013-09-08 11:40 ` Gleb Natapov
2013-09-09 8:31 ` Paolo Bonzini
2013-09-09 9:03 ` Gleb Natapov
2013-09-09 9:53 ` Paolo Bonzini
2013-09-09 10:54 ` Gleb Natapov
2013-09-09 10:58 ` Gleb Natapov
2013-09-09 11:07 ` Paolo Bonzini
2013-09-09 11:28 ` Gleb Natapov
2013-09-09 11:46 ` Paolo Bonzini
2013-09-09 12:00 ` Gleb Natapov [this message]
2013-09-05 13:06 ` [Qemu-devel] [PATCH uq/master 2/2] KVM: make XSAVE support more robust Paolo Bonzini
2013-09-08 11:52 ` Gleb Natapov
2013-09-09 8:51 ` Paolo Bonzini
2013-09-09 9:18 ` Gleb Natapov
2013-09-09 9:50 ` Paolo Bonzini
2013-09-09 10:41 ` Gleb Natapov
2013-09-09 12:00 ` Paolo Bonzini
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=20130909120050.GA6866@redhat.com \
--to=gleb@redhat.com \
--cc=ehabkost@redhat.com \
--cc=kvm@vger.kernel.org \
--cc=pbonzini@redhat.com \
--cc=qemu-devel@nongnu.org \
/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).