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.
