[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [XEN v4] xen/arm64: io: Decode ldr/str post-indexing instructions



On Tue, 25 Jan 2022, Julien Grall wrote:
> > +
> >       /* TODO: Handle ARM instruction */
> >       gprintk(XENLOG_ERR, "unhandled ARM instruction\n");
> >         return 1;
> >   }
> >   +#if CONFIG_ARM_64
> > +void post_increment_register(union ldr_str_instr_class *instr)
> 
> instr should not be modified, so please use const. Also, it would be
> preferrable to pass the regs in parameter. So the none of the decoding code
> relies on the current regs.
> 
> Furthermore, decode.c should only contain code to update the syndrome and in
> theory Arm could decide to provide an valid syndrome in future revision. So I
> would move this code in io.c (or maybe traps.c).

I was the one to suggest moving it to decode.c to keep it closer to the
decoding function it is related to, and also because it felt a bit out
of place in io.c.

I don't feel strongly about this at all; I am fine either way.


> > +{
> > +    struct cpu_user_regs *regs = guest_cpu_user_regs();
> > +    register_t val;
> > +
> > +    /* handle when rn = SP */
> > +    if ( instr->code.rn == 31 )
> > +        val = regs->sp_el1;
> > +    else
> > +        val = get_user_reg(regs, instr->code.rn);
> > +
> > +    val += instr->code.imm9;
> > +
> > +    if ( instr->code.rn == 31 )
> > +        regs->sp_el1 = val;
> > +    else
> > +        set_user_reg(regs, instr->code.rn, val);
> > +}
> > +#endif
> > +
> >   /*
> >    * Local variables:
> >    * mode: C
> > diff --git a/xen/arch/arm/decode.h b/xen/arch/arm/decode.h
> > index 4613763bdb..511cd4a05f 100644
> > --- a/xen/arch/arm/decode.h
> > +++ b/xen/arch/arm/decode.h
> > @@ -23,6 +23,35 @@
> >   #include <asm/regs.h>
> >   #include <asm/processor.h>
> >   +/*
> > + * Refer to the ARMv8 ARM (DDI 0487G.b), Section C4.1.4 Loads and Stores
> > + * Page 318 specifies the following bit pattern for
> > + * "load/store register (immediate post-indexed)".
> > + *
> > + * 31 30 29  27 26 25  23   21 20              11   9         4       0
> > + * ___________________________________________________________________
> > + * |size|1 1 1 |V |0 0 |opc |0 |      imm9     |0 1 |  Rn     |  Rt   |
> > + * |____|______|__|____|____|__|_______________|____|_________|_______|
> > + */
> > +union ldr_str_instr_class {
> > +    uint32_t value;
> > +    struct ldr_str {
> > +        unsigned int rt:5;     /* Rt register */
> > +        unsigned int rn:5;     /* Rn register */
> > +        unsigned int fixed1:2; /* value == 01b */
> > +        signed int imm9:9;            /* imm9 */
> > +        unsigned int fixed2:1; /* value == 0b */
> > +        unsigned int opc:2;    /* opc */
> > +        unsigned int fixed3:2; /* value == 00b */
> > +        unsigned int v:1;      /* vector */
> > +        unsigned int fixed4:3; /* value == 111b */
> > +        unsigned int size:2;   /* size */
> > +    } code;
> > +};
> 
> Looking at the code, post_increment_register() only care about 'rn' and
> 'imm9'. So rather than exposing the full instruction, could we instead provide
> the strict minimum? I.e something like:
> 
> struct
> {
>      enum instr_type; /* Unknown, ldr/str post increment */
>      union
>      {
>          struct
>          {
>            register; /* Register to increment */
>            imm;      /* Immediate to add */
>          } ldr_str;
>      }
>      uint64_t register;
> }
 
The full description helped a lot during review. I would prefer to keep
it if you don't feel strongly about it.



 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.