Re: [Xen-devel] [PATCH v3] Fix the mistake of exception execution

[Aravindh Puthiyaparambil <aravindh@xxxxxxxxxxxx>]

On May 15, 2012 1:15 AM, "Hao, Xudong" <xudong.hao@xxxxxxxxx> wrote:
>
> > -----Original Message-----
> > From: Aravindh Puthiyaparambil [mailto:aravindh@xxxxxxxxxxxx]
> > Sent: Tuesday, May 15, 2012 3:23 PM
> > To: Jan Beulich
> > Cc: Hao, Xudong; Keir Fraser(keir.xen@xxxxxxxxx); Dong, Eddie; Nakajima, Jun;
> > Zhang, Xiantao; xen-devel (xen-devel@xxxxxxxxxxxxx)
> > Subject: Re: [PATCH v3] Fix the mistake of exception execution
> >
> > On Mon, May 14, 2012 at 11:48 PM, Jan Beulich <JBeulich@xxxxxxxx> wrote:
> > >
> > > >>> On 15.05.12 at 07:59, "Hao, Xudong" <xudong.hao@xxxxxxxxx> wrote:
> > > >> From: Jan Beulich [mailto:JBeulich@xxxxxxxx]
> > > >> >>> On 14.05.12 at 12:41, "Hao, Xudong" <xudong.hao@xxxxxxxxx>
> > wrote:
> > > >> >      default:
> > > >> > -        if ( trap > TRAP_last_reserved )
> > > >> > -        {
> > > >> > -            type = X86_EVENTTYPE_SW_EXCEPTION;
> > > >> > -            __vmwrite(VM_ENTRY_INSTRUCTION_LEN, 2); /* int
> > imm8 */
> > > >> > -        }
> > > >>
> > > >> So this undoes Aravindh's earlier change, without replacement. I
> > > >> don't think that's acceptable.
> > > >>
> > > >
> > > > This is the first patch that just correct some instruction in hw exception
> > > > function, as function description above, int n (n > 32) is not delivered by
> > > > this function.
> > > > I'll write another patch of new function for int n handler.
> > >
> > > In that case it would have been nice to indicate that you don't expect
> > > this to be applied just yet (i.e. by marking the patch RFC).
> > >
> > > >> > +                    __vmwrite(VM_ENTRY_INSTRUCTION_LEN,
> > 1); /* int3, CC */
> > > >>
> > > >> Still using a hard-coded 1 here, the more that afaict you can't
> > > >> distinguish CC and CD 03 here.
> > > >>
> > > >
> > > > Just copied it from original code, how about this replacement:
> > > >
> > > > +     __vmwrite(VM_ENTRY_INSTRUCTION_LEN,
> > __vmread(VM_EXIT_INSTRUCTION_LEN));
> > >
> > > That's okay as long as on all possible code paths arriving here
> > > VM_EXIT_INSTRUCTION_LEN is actually valid. I'm suspicious this might
> > > not be the case (especially in the case of injection originating from
> > > libxc).
> >
> > Your suspicion is warranted. IIRC this did not work for the libxc case
> > injecting software interrupts. That is why I hard coded the
> > instruction length. Maybe the instruction length can be made caller
> > specific?
> >
>
> What's traps did you inject? This patch has not handle the software interrupts, but hardware exceptions and #BP, #OF software exceptions.
>

The function handles software interrupts though marked as software exception. Incorrect it might be but it works. Your patch removes that code.

Thanks,
Aravindh

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel