> -----Original Message----- > From: Petre Ovidiu PIRCALABU [mailto:ppircal...@bitdefender.com] > Sent: 23 September 2017 19:57 > To: Paul Durrant <paul.durr...@citrix.com>; xen-devel@lists.xen.org > Cc: Andrew Cooper <andrew.coop...@citrix.com>; Wei Liu > <wei.l...@citrix.com>; sstabell...@kernel.org; Ian Jackson > <ian.jack...@citrix.com>; rcojoc...@bitdefender.com; > konrad.w...@oracle.com; George Dunlap <george.dun...@citrix.com>; > Kevin Tian <kevin.t...@intel.com>; ta...@tklengyel.com; > jbeul...@suse.com; jun.nakaj...@intel.com; Tim (Xen.org) <t...@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
