Hi Simon, On 12/5/19 11:04 PM, Simon Veith wrote: > Hello Eric, > > On 05/12/2019 09:42, Auger Eric wrote: >> Not related to this patch but I noticed SMMU_BASE_ADDR_MASK should be >> 0xffffffffffc0 and not 0xffffffffffe0. I can fix it separately or if you >> respin, you may fix it as well? > > Good catch, thank you. I'll fix it in the next version. > > Looking at the upper end of that mask, it seems that we are currently masking > out bits 48 through 63, rather than just 51 through 63. > The reference manual says that this should be done to match the system > physical address size as given by SMMU_IDR5.OAS. Yes you're right. This should go up to 51 as per the field range definition. Spec says address bits and above this field range are treated as zero. > > We define SMMU_IDR5_OAS to be 4, which selects a physical address size of 44 > bits (ref. section 6.3.6). I think the mask should therefore be 0xfffffffffc0 > to clear bits 44 and above. Do you agree? bits beyond the OAS are RES0. The spec does not says those fields are treated as zero, as explicitly mentioned for bits > 51. Normally the guest should not set them to something != 0, this would be a programming error right? Guest is supposed to read the IDR5 and program accordingly?
> > Ideally, we would derive this mask from our definition of SMMU_IDR5_OAS, but > I'm not sure it's okay to stuff a call to oas2bits() into the > SMMU_BASE_ADDR_MASK macro. Well I am not sure this is worth the candle. I am not sure we are obliged to enforce this. Thanks Eric > > Regards > Simon > > > > Amazon Development Center Germany GmbH > Krausenstr. 38 > 10117 Berlin > Geschaeftsfuehrung: Christian Schlaeger, Ralf Herbrich > Eingetragen am Amtsgericht Charlottenburg unter HRB 149173 B > Sitz: Berlin > Ust-ID: DE 289 237 879 > >
