From: Bandan Das <bsd@redhat.com>
To: Paolo Bonzini <pbonzini@redhat.com>
Cc: Jim Mattson <jmattson@google.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 16:49:18 -0500 [thread overview]
Message-ID: <jpgpn15ufc1.fsf@linux.bootlegged.copy> (raw)
In-Reply-To: <9ff537b7-b204-18fd-6c59-bdb712ed7e20@redhat.com> (Paolo Bonzini's message of "Fri, 12 Feb 2021 22:42:52 +0100")
Paolo Bonzini <pbonzini@redhat.com> writes:
> On 12/02/21 21:56, Jim Mattson wrote:
>>> Not all, we intercept GPs only under a specific condition - just as we
>>> do for vmware_backdoor and for the recent amd errata. IMO, I think it's the right
>>> tradeoff to make to get guest exceptions right.
>> It sounds like I need to get you in my corner to help put a stop to
>> all of the incorrect #UDs that kvm is going to be raising in lieu of
>> #PF when narrow physical address width emulation is enabled!
>
> Ahah :) Apart from the question of when you've entered diminishing
> returns, one important thing to consider is what the code looks
> like. This series is not especially pretty, and that's not your fault.
> The whole idea of special decoding for #GP is a necessary evil for the
> address-check errata, but is it worth extending it to the corner case
> of INVPCID for CPL>0?
>
Sure, no worries. I will have fond memories of the time I spent extra time
on a trivial patch to address Jim's concerns(ofcourse valid!) only to find out
now he has changed his mind.
Bandan
> Paolo
prev parent reply other threads:[~2021-02-12 21:50 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
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 [this message]
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=jpgpn15ufc1.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.