[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [XEN v9 2/4] xen/arm64: io: Support instructions (for which ISS is not valid) on emulated MMIO region using MMIO/ioreq handler
On Fri, 4 Mar 2022, Julien Grall wrote: > Hi Stefano, > > On 04/03/2022 00:42, Stefano Stabellini wrote: > > > void register_mmio_handler(struct domain *d, > > > diff --git a/xen/arch/arm/ioreq.c b/xen/arch/arm/ioreq.c > > > index 308650b400..58cd320b5a 100644 > > > --- a/xen/arch/arm/ioreq.c > > > +++ b/xen/arch/arm/ioreq.c > > > @@ -47,6 +47,7 @@ enum io_state try_fwd_ioserv(struct cpu_user_regs *regs, > > > struct vcpu *v, mmio_info_t *info) > > > { > > > struct vcpu_io *vio = &v->io; > > > + struct dabt_instr instr = info->dabt_instr; > > > ioreq_t p = { > > > .type = IOREQ_TYPE_COPY, > > > .addr = info->gpa, > > > @@ -76,10 +77,10 @@ enum io_state try_fwd_ioserv(struct cpu_user_regs > > > *regs, > > > if ( !s ) > > > return IO_UNHANDLED; > > > - if ( !info->dabt.valid ) > > > - return IO_ABORT; > > > + ASSERT(dabt.valid); > > > > I cannot see where we set dabt.valid on successfully decoding the > > instruction. It looks like we don't? If we don't, then here the ASSERT > > would fail in case of postindexing instructions, right? > > We don't currently set dabt.valid. There are other reasons to set it (see my > reply to Ayan). So... > > > > > If we don't, then we should probably just get rid of this ASSERT: it is > > not worth setting dabt.valid just so that this ASSERT would succeed. > > ... I would keep the ASSERT. OK
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |