Re: [PATCH v2 00/21] KVM: x86: Event/exception fixes and cleanups

[Jim Mattson]

On Thu, Jun 30, 2022 at 1:22 AM Maxim Levitsky <mlevitsk@xxxxxxxxxx> wrote:
>
> On Wed, 2022-06-29 at 06:42 -0700, Jim Mattson wrote:

> > Unlike the AMD "INTn intercept," these trap intercepts *do not* happen
> > at the start of the instruction.
>
> Are you sure about that?

I had been sure when I wrote that, but now that I see your response, I
have to question my memory. The SDM is definitely more authoritative
than I am.

> > When you say "ignores," do you mean that AMD ignores a data breakpoint
> > or single-step trap generated by MOV-SS, or it ignores the fact that
> > delivering such a #DB trap between the MOV-SS and the subsequent
> > MOV-ESP will create a stack frame in the wrong place?
>
> Two things which can be infered from the SVM spec.
>         - AMD doesn't distinguish between MOV SS and STI int shadow.
>         - AMD has no 'pending debug exception field' in the vmcb.
>
> I don't know what AMD does for #DB that happens on MOV SS, nor if it
> does distinguish these internally,
> probably just drops the #DB or something.

Without carrying pending debug exceptions, it seems that the only two
choices are to deliver the #DB, with the exception frame in an
unintended location or to drop the #DB. The latter seems preferable,
but neither one seems good. What I don't understand is why you claim
that AMD does this "rightfully." Are you saying that anyone with the
audacity to run a debugger on legacy code deserves to be thrown in
front of a moving train?

> > Hence, the facility for injecting a "pending MTF"--so that it won't be "lost."
> Yes, though that is would be mostly useful for nesting.
>
> For not nesting hypervisor, if the hypervisor figured out that a higher priority event overrode
> the MTF, it can just process the MTF - why to re-inject it?

You're right. The facility is probably just there to make MTF
virtualizable. Intel was paying much closer attention to
virtualizability by the time MTF came along.

> >
> > These are single-step, I/O and data breakpoint traps.
>
> I am not sure what you mean. single-step, IO, data breakpoints are indeed the trap #DB,
> while "general detect", code breakpoint are fault #DB, and we also have the task switch #DB, but since the hardware doesn't
> emulate the task switches, this has to be injected.

Just enumerating. No more, no less.