lkml.org 
[lkml]   [2020]   [Jun]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRE: [PATCH 3/3] KVM:SVM: Enable INVPCID feature on AMD
From
Date


> -----Original Message-----
> From: Paolo Bonzini <pbonzini@redhat.com>
> Sent: Monday, June 15, 2020 8:47 AM
> To: Jim Mattson <jmattson@google.com>; Moger, Babu
> <Babu.Moger@amd.com>
> Cc: Wanpeng Li <wanpengli@tencent.com>; Joerg Roedel <joro@8bytes.org>;
> the arch/x86 maintainers <x86@kernel.org>; Sean Christopherson
> <sean.j.christopherson@intel.com>; Ingo Molnar <mingo@redhat.com>;
> Borislav Petkov <bp@alien8.de>; H . Peter Anvin <hpa@zytor.com>; Vitaly
> Kuznetsov <vkuznets@redhat.com>; Thomas Gleixner <tglx@linutronix.de>;
> LKML <linux-kernel@vger.kernel.org>; kvm list <kvm@vger.kernel.org>
> Subject: Re: [PATCH 3/3] KVM:SVM: Enable INVPCID feature on AMD
>
> On 13/06/20 02:04, Jim Mattson wrote:
> >> I think I have misunderstood this part. I was not inteding to change the
> >> #GP behaviour. I will remove this part. My intension of these series is to
> >> handle invpcid in shadow page mode. I have verified that part. Hope I did
> >> not miss anything else.
> > You don't really have to intercept INVPCID when tdp is in use, right?
> > There are certainly plenty of operations for which kvm does not
> > properly raise #UD when they aren't enumerated in the guest CPUID.
> >
>
> Indeed; for RDRAND and RDSEED it makes sense to do so because the
> instructions may introduce undesirable nondeterminism (or block all the
> packages in your core as they have been doing for a few weeks).
> Therefore on Intel we trap them and raise #UD; on AMD this is not
> possible because RDRAND has no intercept.
>
> In general however we do not try to hard to raise #UD and that is
> usually not even possible.

Yes. Sure. Thanks.
>
> Paolo

\
 
 \ /
  Last update: 2020-06-15 17:00    [W:0.111 / U:0.104 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site