Bruce Rogers
2008-Jan-14 22:57 UTC
[Xen-devel] unstable changeset 16667 introduced regression
Keir, I''ve narrowed down a problem we are now seeing with Virtualized NetWare when run on current unstable. It started occurring with changeset 16667, which dealt with debugger changes. When encountering the INT 3 instruction (opcode 0xcc), the EIP value provided in the exception frame is supposed to be at the next instruction following the INT 3 instruction. With this patch included, the EIP value ends up being one byte further into the instruction stream. I haven''t seen where in this patch the problem is coming from, but will keep looking. - Bruce _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Keir Fraser
2008-Jan-15 08:21 UTC
Re: [Xen-devel] unstable changeset 16667 introduced regression
Can you explain the scenario in more detail? Do you mean the EIP has not been incremented past the 0xcc opcode? I think the change from set_system_gate() to set_intr_gate() in that patch is very dubious, now I take another look at it. I should probably at least revert that, as it''s probably causing guest INT3s to be delivered to Xen as GPFs, with no corresponding increment of EIP. I can''t see how any other change in the patch would affect guest execution when gdbstub is not involved as almost all other changes are to gdbstub code. And probably you are not building Xen with crash_debug=y? -- Keir On 14/1/08 22:57, "Bruce Rogers" <BROGERS@novell.com> wrote:> Keir, > I''ve narrowed down a problem we are now seeing with Virtualized NetWare when > run on current unstable. > It started occurring with changeset 16667, which dealt with debugger changes. > When encountering the INT 3 instruction (opcode 0xcc), the EIP value provided > in the exception frame is supposed to be at the next instruction following the > INT 3 instruction. With this patch included, the EIP value ends up being one > byte further into the instruction stream. > > I haven''t seen where in this patch the problem is coming from, but will keep > looking. > > - Bruce > > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xensource.com > http://lists.xensource.com/xen-devel_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Keir Fraser
2008-Jan-15 08:24 UTC
Re: [Xen-devel] unstable changeset 16667 introduced regression
Oh, you really do mean that the EIP is incremented by 2 bytes rather than 1. This is explained by the fact that Xen receives a GPF fault, determines this is due to a software-interrupt/exception attempt by the guest, and ''emulates'' the instruction by reflecting the interrupt to the guest and incrementing EIP across ''INT <n>'', which happens to be a two-byte instruction. I''ll fix this for 3.2.0. -- Keir On 15/1/08 08:21, "Keir Fraser" <Keir.Fraser@cl.cam.ac.uk> wrote:> Can you explain the scenario in more detail? Do you mean the EIP has not > been incremented past the 0xcc opcode? I think the change from > set_system_gate() to set_intr_gate() in that patch is very dubious, now I > take another look at it. I should probably at least revert that, as it''s > probably causing guest INT3s to be delivered to Xen as GPFs, with no > corresponding increment of EIP. > > I can''t see how any other change in the patch would affect guest execution > when gdbstub is not involved as almost all other changes are to gdbstub > code. And probably you are not building Xen with crash_debug=y? > > -- Keir > > On 14/1/08 22:57, "Bruce Rogers" <BROGERS@novell.com> wrote: > >> Keir, >> I''ve narrowed down a problem we are now seeing with Virtualized NetWare when >> run on current unstable. >> It started occurring with changeset 16667, which dealt with debugger changes. >> When encountering the INT 3 instruction (opcode 0xcc), the EIP value provided >> in the exception frame is supposed to be at the next instruction following >> the >> INT 3 instruction. With this patch included, the EIP value ends up being one >> byte further into the instruction stream. >> >> I haven''t seen where in this patch the problem is coming from, but will keep >> looking. >> >> - Bruce >> >> >> _______________________________________________ >> Xen-devel mailing list >> Xen-devel@lists.xensource.com >> http://lists.xensource.com/xen-devel > > > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xensource.com > http://lists.xensource.com/xen-devel_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Bruce Rogers
2008-Jan-15 14:38 UTC
Re: [Xen-devel] unstable changeset 16667 introduced regression
Great! Thanks for figuring this out. - Bruce>>> Keir Fraser <Keir.Fraser@cl.cam.ac.uk> 01/15/08 1:24 AM >>>Oh, you really do mean that the EIP is incremented by 2 bytes rather than 1. This is explained by the fact that Xen receives a GPF fault, determines this is due to a software-interrupt/exception attempt by the guest, and ''emulates'' the instruction by reflecting the interrupt to the guest and incrementing EIP across ''INT <n>'', which happens to be a two-byte instruction. I''ll fix this for 3.2.0. -- Keir On 15/1/08 08:21, "Keir Fraser" <Keir.Fraser@cl.cam.ac.uk> wrote:> Can you explain the scenario in more detail? Do you mean the EIP has not > been incremented past the 0xcc opcode? I think the change from > set_system_gate() to set_intr_gate() in that patch is very dubious, now I > take another look at it. I should probably at least revert that, as it''s > probably causing guest INT3s to be delivered to Xen as GPFs, with no > corresponding increment of EIP. > > I can''t see how any other change in the patch would affect guest execution > when gdbstub is not involved as almost all other changes are to gdbstub > code. And probably you are not building Xen with crash_debug=y? > > -- Keir > > On 14/1/08 22:57, "Bruce Rogers" <BROGERS@novell.com> wrote: > >> Keir, >> I''ve narrowed down a problem we are now seeing with Virtualized NetWare when >> run on current unstable. >> It started occurring with changeset 16667, which dealt with debugger changes. >> When encountering the INT 3 instruction (opcode 0xcc), the EIP value provided >> in the exception frame is supposed to be at the next instruction following >> the >> INT 3 instruction. With this patch included, the EIP value ends up being one >> byte further into the instruction stream. >> >> I haven''t seen where in this patch the problem is coming from, but will keep >> looking. >> >> - Bruce >> >> >> _______________________________________________ >> Xen-devel mailing list >> Xen-devel@lists.xensource.com >> http://lists.xensource.com/xen-devel > > > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xensource.com > http://lists.xensource.com/xen-devel_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel