On Mon, 20 Aug 2018, Julien Grall wrote: > Hi Stefano, > > On Thu, 16 Aug 2018, 19:17 Stefano Stabellini, <sstabell...@kernel.org> wrote: > On Thu, 16 Aug 2018, Julien Grall wrote: > > Hi Stefano, > > > > On 08/14/2018 10:43 PM, Stefano Stabellini wrote: > > > On Mon, 16 Jul 2018, Julien Grall wrote: > > > > GUEST_BUG_ON may be used in other files doing guest emulation. > > > > > > > > Signed-off-by: Julien Grall <julien.gr...@linaro.org> > > > > > > Given that GUEST_BUG_ON is not actually used in any other files in > this > > > patch series, I assume you are referring to one of your future > series? > > > > It is going to be used later. However, I don't really refer to any > series in > > particular. It is just that this macros could be helpful in any > emulation code > > to catch what we think is a invalid architectural behavior. > > It is only that a concrete use-case helps. The idea of moving > GUEST_BUG_ON is good, but where to? For instance, wouldn't it be better > to move it to guest_access.h? I am just trying to point to an existing > header which is more widely used across the emulators (vpl011, > vgic-v3-its.c, hvm.c, ...) > > > Definitely not in guest_access.h or any wider in includes. If you look at the > implementation and documentation, it will crash the > hypervisor because the goal is to catch hardware bug or misunderstanding of > the spec. This is not meant to be used in emulation. > We should not crash the guest/hypervisor in bad behavior but inject an > exception. > > So trap.h is the best places for it as hardware trap are now split accros > multiples files.
OK _______________________________________________ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel