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.

> thanks
> -- PMM

Reply via email to