[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <d930d842-6283-f271-b6b1-60c245b69bff@redhat.com>
Date: Tue, 14 Mar 2017 10:55:49 +0100
From: Paolo Bonzini <pbonzini@...hat.com>
To: Jim Mattson <jmattson@...gle.com>
Cc: LKML <linux-kernel@...r.kernel.org>,
kvm list <kvm@...r.kernel.org>, bdas@...hat.com,
David Matlack <dmatlack@...gle.com>
Subject: Re: [PATCH 6/6] KVM: nVMX: support RDRAND and RDSEED exiting
On 13/03/2017 19:27, Jim Mattson wrote:
> I would expect that any reasonable CPU will support "RDRAND exiting"
> iff it supports RDRAND (i.e. CPUID.01H:ECX.RDRAND[bit 30]).
> Similarly, any reasonable CPU will support "RDSEED exiting" iff it
> supports RDSEED (i.e. CPUID.(EAX=07H, ECX=0H):EBX.RDSEED[bit 18]).
>
> Shouldn't there be some code in vmx_cpuid_update to adjust the
> vmx->nested.nested_vmx_secondary_ctls_high bits for "RDRAND exiting"
> and "RDSEED exiting," as there already is for "enable RDTSCP"?
Enable RDTSCP is a bit different in that the instruction itself is
disabled rather than the VMEXIT, still it would probably be a good idea.
One thing to be careful about is any conflicts with David Matlack's work
to customize the MSRs for processor models, since there's no prescribed
ordering of KVM_SET_CPUID2 and KVM_SET_MSR. Maybe
nested_vmx_setup_ctls_msrs can save the "default" nested_*_ctls_*; then
vmx_restore_control_msr can refer to those in order to check the written
value against the supported bits.
Paolo
Powered by blists - more mailing lists