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

[Paul Durrant <Paul.Durrant@citrix.com>]

> -----Original Message-----
> From: Petre Ovidiu PIRCALABU [mailto:ppircalabu@bitdefender.com]
> Sent: 23 September 2017 19:57
> To: Paul Durrant <Paul.Durrant@citrix.com>; xen-devel@lists.xen.org
> Cc: Andrew Cooper <Andrew.Cooper3@citrix.com>; Wei Liu
> <wei.liu2@citrix.com>; sstabellini@kernel.org; Ian Jackson
> <Ian.Jackson@citrix.com>; rcojocaru@bitdefender.com;
> konrad.wilk@oracle.com; George Dunlap <George.Dunlap@citrix.com>;
> Kevin Tian <kevin.tian@intel.com>; tamas@tklengyel.com;
> jbeulich@suse.com; jun.nakajima@intel.com; Tim (Xen.org) <tim@xen.org>
> 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@lists.xen.org
https://lists.xen.org/xen-devel