Hi Peter, On 05/16/2018 06:18 PM, Peter Maydell wrote: > On 16 May 2018 at 15:33, Auger Eric <eric.au...@redhat.com> wrote: >> On 05/08/2018 06:25 PM, Peter Maydell wrote: >>> This runs into something I found when I was implementing the Arm >>> Memory Protection Controller -- at the point when the guest changes >>> the config, >> do you mean the config structures (STE, CD) or the page table update? > > The Memory Protection Controller is not the SMMUv3. The MPC > config is set using some registers to write to the MPC's LUT > (lookup table). > >> it doesn't have enough information to be able to call a >>> "map" notifier, because the mapping depends on the memory transaction >>> attributes, it's not fixed and dependent only on the address. >> >> I am not sure I understand what you mean here. When the notifier get's >> called, aren't we supposed to look for the info in the actual page table >> (where memory access control attributes and others can be found at that >> time, ie. ARM AP[] for instance) and send those through the notifier (as >> stored in the IOTLBEnry)? > > The problem is that if your translations depend on the tx attributes, > ie "secure access to address X should translate to Y, but nonsecure > access to address X should translate to Z", then the notifier > API doesn't let you report that, because all it knows about is > unmap events which are "address X unmapped" and map events which > are "address X translates to Y". > > Paolo has suggested some API changes in another thread (roughly, > having the notifier say which tx attributes matter for the translation, > and send multiple map events with appropriate information). > >> For instance in the intel iommu code, the whole table is parsed and the >> replay hook is called for all valid entries. > > This works because the intel iommu does not care about memory > transaction attributes: it has one translation for the input > address, regardless.
OK I get it now. Thank you for the explanations. Eric > > thanks > -- PMM >
