Messages in this thread | | | Subject | RE: [PATCH 3/3] KVM:SVM: Enable INVPCID feature on AMD | From | Babu Moger <> | Date | Mon, 15 Jun 2020 09:59:09 -0500 |
| |
> -----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
| |