Re: [Xen-devel] [PATCH v12 1/4] x86emul: New return code for unimplemented instruction

[Paul Durrant <Paul.Durrant@xxxxxxxxxx>]

> -----Original Message-----
> From: Petre Ovidiu PIRCALABU [mailto:ppircalabu@xxxxxxxxxxxxxxx]
> Sent: 23 September 2017 19:57
> To: Paul Durrant <Paul.Durrant@xxxxxxxxxx>; xen-devel@xxxxxxxxxxxxx
> Cc: Andrew Cooper <Andrew.Cooper3@xxxxxxxxxx>; Wei Liu
> <wei.liu2@xxxxxxxxxx>; sstabellini@xxxxxxxxxx; Ian Jackson
> <Ian.Jackson@xxxxxxxxxx>; rcojocaru@xxxxxxxxxxxxxxx;
> konrad.wilk@xxxxxxxxxx; George Dunlap <George.Dunlap@xxxxxxxxxx>;
> Kevin Tian <kevin.tian@xxxxxxxxx>; tamas@xxxxxxxxxxxxx;
> jbeulich@xxxxxxxx; jun.nakajima@xxxxxxxxx; Tim (Xen.org) <tim@xxxxxxx>
> Subject: Re: [PATCH v12 1/4] x86emul: New return code for unimplemented
> instruction
> 
> On Thu, 2017-09-21 at 08:53 +0000, Paul Durrant wrote:
> > >      }
> > > +    case X86EMUL_UNIMPLEMENTED:
> > > +        ASSERT_UNREACHABLE();
> > > +        /* Fall-through */
> >
> > Kind of surprised you need the fall-through if you assert the code is
> > unreachable... but analysis tools can be a bit temperamental so ok.
> >
> > >      default:
> > >          BUG();
> > >      }
> > >
> > > +    ASSERT(rc != X86EMUL_UNIMPLEMENTED);
> > > +
> >
> > Isn't this assertion redundant given the ASSERT_UNREACHABLE() above?
> >
> >
> > >   Paul
> 
> The second ASSERT statement is used to make sure the return value of
> hvm_process_io_intercept or hvm_send_ioreq (called from the "case
> X86EMUL_UNHANDLEABLE:" branch of the switch statement above) cannot
> be X86EMUL_UNIMPLEMENTED.

Ah, ok. Just out of context in the patch.

  Paul

> 
> > hvm_process_io_intercept
> > >      if ( rc != X86EMUL_OKAY )
> > >          return rc;
> > >
> > >
> //Petre
> 
> ________________________
> This email was scanned by Bitdefender
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
https://lists.xen.org/xen-devel