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. thanks -- PMM
