From: Bandan Das <bsd@redhat.com>
To: Jim Mattson <jmattson@google.com>
Cc: Paolo Bonzini <pbonzini@redhat.com>,
kvm list <kvm@vger.kernel.org>, "Huang2\,
Wei" <wei.huang2@amd.com>, "Moger\, Babu" <babu.moger@amd.com>
Subject: Re: [PATCH 0/3] AMD invpcid exception fix
Date: Fri, 12 Feb 2021 12:55:15 -0500 [thread overview]
Message-ID: <jpg35y1f9x8.fsf@linux.bootlegged.copy> (raw)
In-Reply-To: <CALMp9eQ370MQ1ZPtby4ezodCga9wDeXXGTcrqoXjj03WPJOEhQ@mail.gmail.com> (Jim Mattson's message of "Fri, 12 Feb 2021 09:43:10 -0800")
Jim Mattson <jmattson@google.com> writes:
> On Fri, Feb 12, 2021 at 6:49 AM Bandan Das <bsd@redhat.com> wrote:
>>
>> Paolo Bonzini <pbonzini@redhat.com> writes:
>>
>> > On 11/02/21 22:22, Bandan Das wrote:
>> >> The pcid-disabled test from kvm-unit-tests fails on a Milan host because the
>> >> processor injects a #GP while the test expects #UD. While setting the intercept
>> >> when the guest has it disabled seemed like the obvious thing to do, Babu Moger (AMD)
>> >> pointed me to an earlier discussion here - https://lkml.org/lkml/2020/6/11/949
>> >>
>> >> Jim points out there that #GP has precedence over the intercept bit when invpcid is
>> >> called with CPL > 0 and so even if we intercept invpcid, the guest would end up with getting
>> >> and "incorrect" exception. To inject the right exception, I created an entry for the instruction
>> >> in the emulator to decode it successfully and then inject a UD instead of a GP when
>> >> the guest has it disabled.
>> >>
>> >> Bandan Das (3):
>> >> KVM: Add a stub for invpcid in the emulator table
>> >> KVM: SVM: Handle invpcid during gp interception
>> >> KVM: SVM: check if we need to track GP intercept for invpcid
>> >>
>> >> arch/x86/kvm/emulate.c | 3 ++-
>> >> arch/x86/kvm/svm/svm.c | 22 +++++++++++++++++++++-
>> >> 2 files changed, 23 insertions(+), 2 deletions(-)
>> >>
>> >
>> > Isn't this the same thing that "[PATCH 1/3] KVM: SVM: Intercept
>> > INVPCID when it's disabled to inject #UD" also does?
>> >
>> Yeah, Babu pointed me to Sean's series after I posted mine.
>> 1/3 indeed will fix the kvm-unit-test failure. IIUC, It doesn't look like it
>> handles the case for the guest executing invpcid at CPL > 0 when it's
>> disabled for the guest - #GP takes precedence over intercepts and will
>> be incorrectly injected instead of an #UD.
>
> I know I was the one to complain about the #GP, but...
>
> As a general rule, kvm cannot always guarantee a #UD for an
> instruction that is hidden from the guest. Consider, for example,
> popcnt, aesenc, vzeroall, movbe, addcx, clwb, ...
> I'm pretty sure that Paolo has brought this up in the past when I've
> made similar complaints.
Ofcourse, even for vm instructions failures, the fixup table always jumps
to a ud2. I was just trying to address the concern because it is possible
to inject the correct exception via decoding the instruction.
Bandan
next prev parent reply other threads:[~2021-02-12 17:57 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-02-11 21:22 [PATCH 0/3] AMD invpcid exception fix Bandan Das
2021-02-11 21:22 ` [PATCH 1/3] KVM: Add a stub for invpcid in the emulator table Bandan Das
2021-02-11 21:22 ` [PATCH 2/3] KVM: SVM: Handle invpcid during gp interception Bandan Das
2021-02-11 21:22 ` [PATCH 3/3] KVM: SVM: check if we need to track GP intercept for invpcid Bandan Das
2021-02-12 10:51 ` [PATCH 0/3] AMD invpcid exception fix Paolo Bonzini
2021-02-12 14:49 ` Bandan Das
2021-02-12 17:43 ` Jim Mattson
2021-02-12 17:55 ` Bandan Das [this message]
2021-02-12 18:20 ` Jim Mattson
2021-02-12 18:35 ` Bandan Das
2021-02-12 19:40 ` Jim Mattson
2021-02-12 20:09 ` Bandan Das
2021-02-12 20:56 ` Jim Mattson
2021-02-12 21:42 ` Paolo Bonzini
2021-02-12 21:49 ` Bandan Das
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=jpg35y1f9x8.fsf@linux.bootlegged.copy \
--to=bsd@redhat.com \
--cc=babu.moger@amd.com \
--cc=jmattson@google.com \
--cc=kvm@vger.kernel.org \
--cc=pbonzini@redhat.com \
--cc=wei.huang2@amd.com \
/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.