Messages in this thread | | | From | Jim Mattson <> | Date | Thu, 30 Jun 2022 09:28:36 -0700 | Subject | Re: [PATCH v2 00/21] KVM: x86: Event/exception fixes and cleanups |
| |
On Thu, Jun 30, 2022 at 1:22 AM Maxim Levitsky <mlevitsk@redhat.com> 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.
| |