[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH v2 1/1] memory.h: Improve IOMMU related document

From: Auger Eric
Subject: Re: [Qemu-devel] [PATCH v2 1/1] memory.h: Improve IOMMU related documentation
Date: Thu, 17 May 2018 09:36:47 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0

Hi Peter,
On 05/16/2018 06:18 PM, Peter Maydell wrote:
> On 16 May 2018 at 15:33, Auger Eric <address@hidden> 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

[Prev in Thread] Current Thread [Next in Thread]