From: Paolo Bonzini <pbonzini@redhat.com>
To: Gleb Natapov <gleb@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 17:24:20 +0200 [thread overview]
Message-ID: <52405D24.1010708@redhat.com> (raw)
In-Reply-To: <20130923150955.GB10353@redhat.com>
Il 23/09/2013 17:09, Gleb Natapov ha scritto:
> 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);
Ok.
>
>> I preferred this to adding dubiously-testable code that probed CPUID for
>> SSE support (or should I check FXSR instead?)
I didn't understand you wanted the "| XSTATE_FPSSE" moved, I thought you
wanted to check for SSE bits in userspace (similar to AVX). I wasn't
sure whether to tie this to the SSE bit, or to FXSR. But what you
propose makes sense, I'll test it.
Paolo
next prev parent reply other threads:[~2013-09-23 15:24 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
2013-09-23 15:24 ` Paolo Bonzini [this message]
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=52405D24.1010708@redhat.com \
--to=pbonzini@redhat.com \
--cc=gleb@redhat.com \
--cc=linux-kernel@vger.kernel.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 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.