[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.
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |