On 9/20/2017 4:13 PM, Paolo Bonzini wrote:
On 20/09/2017 08:35, Yu Zhang wrote:
2 reasons I did not choose to change kvm_cpuid(): 1> like Jim's
comments, kvm_cpuid() will eventually write the *eax - *edx no
matter a cpuid entry is found or not; 2> currently, return value of
kvm_cpuid() is eith
On 20/09/2017 08:35, Yu Zhang wrote:
>
> 2 reasons I did not choose to change kvm_cpuid(): 1> like Jim's
> comments, kvm_cpuid() will eventually write the *eax - *edx no
> matter a cpuid entry is found or not; 2> currently, return value of
> kvm_cpuid() is either true when an entry is found or fal
On 9/18/2017 11:56 PM, Jim Mattson wrote:
kvm_cpuid ultimately wants to write all four of the GPRs passed in by
reference. I don't see any advantage to allowing some of these
pointers to be NULL.
Thanks for your comments, Jim & David.
2 reasons I did not choose to change kvm_cpuid():
1> like
kvm_cpuid ultimately wants to write all four of the GPRs passed in by
reference. I don't see any advantage to allowing some of these
pointers to be NULL.
Reviewed-by: Jim Mattson
On Mon, Sep 18, 2017 at 5:19 AM, David Hildenbrand wrote:
> On 18.09.2017 12:45, Yu Zhang wrote:
>> Routine check_cr
On 18.09.2017 12:45, Yu Zhang wrote:
> Routine check_cr_write() will trigger emulator_get_cpuid()->
> kvm_cpuid() to get maxphyaddr, and NULL is passed as values
> for ebx/ecx/edx. This is problematic because kvm_cpuid() will
> dereference these pointers.
>
> Fixes: d1cd3ce90044 ("KVM: MMU: check
5 matches
Mail list logo