All of lore.kernel.org
 help / color / mirror / Atom feed
From: Gleb Natapov <gleb@redhat.com>
To: Paolo Bonzini <pbonzini@redhat.com>
Cc: linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2 2/3] KVM: x86: prevent setting unsupported XSAVE states
Date: Mon, 23 Sep 2013 18:09:55 +0300	[thread overview]
Message-ID: <20130923150955.GB10353@redhat.com> (raw)
In-Reply-To: <5240166D.5020401@redhat.com>

On Mon, Sep 23, 2013 at 12:22:37PM +0200, Paolo Bonzini wrote:
> >> @@ -6940,6 +6948,9 @@ int kvm_arch_vcpu_init(struct kvm_vcpu *vcpu)
> >>  
> >>  	vcpu->arch.ia32_tsc_adjust_msr = 0x0;
> >>  	vcpu->arch.pv_time_enabled = false;
> >> +
> >> +	vcpu->arch.supported_xcr0 = XSTATE_FPSSE;
> >> +
> > Why is this needed? It will make make __kvm_set_xcr() succeed if attempt
> > is made to set SSE bit when it is not supported in cpuid. This may not
> > be an issue in practice, but for clarity it is better for supported_xcr0
> > to contain only what is supported in guest's cpuid bits and handle the
> > fact that FP/SSE state should always be copied to/from userspace in
> > kvm_vcpu_ioctl_x86_(set|get)_xsave functions.
> 
> I don't think it makes sense to disable SSE but not XSAVE.  Linux even
> has this:
> 
>         if ((pcntxt_mask & XSTATE_FPSSE) != XSTATE_FPSSE) {
>                 pr_err("FP/SSE not shown under xsave features 0x%llx\n",
>                        pcntxt_mask);
>                 BUG();
>         }
>
That's why I said it may not be an issue in practice. What makes the
code confusing to me is that it is not clear what .supported_xcr0
contains. Why not make it contain only guest cpuid bits and use
XSTATE_FPSSE explicitly in get_xsave. I mean drop this from next patch:

        vcpu->arch.supported_xcr0 =
-               (best->eax | ((u64)best->edx << 32)) &
+               (best->eax | ((u64)best->edx << 32) | XSTATE_FPSSE) &
                host_xcr0 & KVM_SUPPORTED_XCR0;

And change
*(u64 *)&guest_xsave->region[XSAVE_HDR_OFFSET / sizeof(u32)] !=  vcpu->arch.supported_xcr0;
to
*(u64 *)&guest_xsave->region[XSAVE_HDR_OFFSET / sizeof(u32)] != (vcpu->arch.supported_xcr0 | XSTATE_FPSSE);


> I preferred this to adding dubiously-testable code that probed CPUID for
> SSE support (or should I check FXSR instead?)
> 
Not sure I understand.

--
			Gleb.

  reply	other threads:[~2013-09-23 15:09 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-09-16 14:26 [PATCH v2 0/3] KVM: prepare for future XSAVE extensions Paolo Bonzini
2013-09-16 14:26 ` [PATCH v2 1/3] KVM: x86: mask unsupported XSAVE entries from leaf 0Dh index 0 Paolo Bonzini
2013-09-16 14:26 ` [PATCH v2 2/3] KVM: x86: prevent setting unsupported XSAVE states Paolo Bonzini
2013-09-22  9:33   ` Gleb Natapov
2013-09-23 10:22     ` Paolo Bonzini
2013-09-23 15:09       ` Gleb Natapov [this message]
2013-09-23 15:24         ` Paolo Bonzini
2013-09-16 14:26 ` [PATCH v2 3/3] KVM: x86: only copy XSAVE state for the supported features 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=20130923150955.GB10353@redhat.com \
    --to=gleb@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=pbonzini@redhat.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.