On 25 May 2018 at 10:27, Auger Eric wrote:
> I fail to understand the PRIV attribute usage in SMMUv3.
> My understanding is the STRW (ie. stream world, kind of indication of
> the exception level the SID is used along) in the STE is used to
> determine the correct TTB*. Isn't PRIV checked against
Hi Peter,
On 05/24/2018 12:54 PM, Peter Maydell wrote:
> On 24 May 2018 at 07:23, Peter Xu wrote:
>> On Wed, May 23, 2018 at 12:47:16PM +0100, Peter Maydell wrote:
>>> On 23 May 2018 at 02:06, Peter Xu wrote:
Could you elaborate a bit more on why IOMMU notifier failed to
corporate when
On Thu, May 24, 2018 at 11:54:17AM +0100, Peter Maydell wrote:
> On 24 May 2018 at 07:23, Peter Xu wrote:
> > On Wed, May 23, 2018 at 12:47:16PM +0100, Peter Maydell wrote:
> >> On 23 May 2018 at 02:06, Peter Xu wrote:
> >> > Could you elaborate a bit more on why IOMMU notifier failed to
> >> > c
On 24 May 2018 at 07:23, Peter Xu wrote:
> On Wed, May 23, 2018 at 12:47:16PM +0100, Peter Maydell wrote:
>> On 23 May 2018 at 02:06, Peter Xu wrote:
>> > Could you elaborate a bit more on why IOMMU notifier failed to
>> > corporate when passing in MemTxAttrs? I am not sure I caught the idea
>>
On Wed, May 23, 2018 at 12:47:16PM +0100, Peter Maydell wrote:
> On 23 May 2018 at 02:06, Peter Xu wrote:
> > On Tue, May 22, 2018 at 12:11:38PM +0100, Peter Maydell wrote:
> >> On 22 May 2018 at 12:02, Peter Xu wrote:
> >> > On Tue, May 22, 2018 at 09:40:44AM +0100, Peter Maydell wrote:
>
> >>
On 23 May 2018 at 02:06, Peter Xu wrote:
> On Tue, May 22, 2018 at 12:11:38PM +0100, Peter Maydell wrote:
>> On 22 May 2018 at 12:02, Peter Xu wrote:
>> > On Tue, May 22, 2018 at 09:40:44AM +0100, Peter Maydell wrote:
>> > And if we see current implementation for this (still, I copied code
>> >
On Tue, May 22, 2018 at 12:11:38PM +0100, Peter Maydell wrote:
> On 22 May 2018 at 12:02, Peter Xu wrote:
> > On Tue, May 22, 2018 at 09:40:44AM +0100, Peter Maydell wrote:
> >> On 22 May 2018 at 04:03, Peter Xu wrote:
> >> The reason for not just passing in the transaction attributes to
> >> tra
On 05/22/2018 10:51 AM, Peter Maydell wrote:
> That wouldn't allow for multiple instances of the same class where the
> answer is different (eg "my_iommu->has_trustzone_support ? 2 : 1" where
> the answer depends on how the instance is configured via QOM properties).
Ah. I had somehow been assumi
On 22 May 2018 at 18:42, Richard Henderson wrote:
> On 05/21/2018 07:03 AM, Peter Maydell wrote:
>> +/* Return the IOMMU index to use for a given set of transaction
>> attributes.
>> + *
>> + * Optional method: if an IOMMU only supports a single IOMMU index then
>> + * the default
On 05/21/2018 07:03 AM, Peter Maydell wrote:
> +/* Return the IOMMU index to use for a given set of transaction
> attributes.
> + *
> + * Optional method: if an IOMMU only supports a single IOMMU index then
> + * the default implementation of memory_region_iommu_attrs_to_index()
>
On 05/22/2018 04:19 PM, Peter Maydell wrote:
> On 22 May 2018 at 15:11, Auger Eric wrote:
>> Hi Peter,
>>
>> On 05/22/2018 03:22 PM, Peter Maydell wrote:
>>> How many substream IDs do we expect to see in practice?
>>
>> Spec says max 20 bits, matching the max size of the PASID
>
> Right, but do
On 22 May 2018 at 15:11, Auger Eric wrote:
> Hi Peter,
>
> On 05/22/2018 03:22 PM, Peter Maydell wrote:
>> How many substream IDs do we expect to see in practice?
>
> Spec says max 20 bits, matching the max size of the PASID
Right, but do we actually expect to see transactions from
devices that u
Hi Peter,
On 05/22/2018 03:22 PM, Peter Maydell wrote:
> On 22 May 2018 at 13:58, Auger Eric wrote:
>> Hi Peter,
>> On 05/21/2018 04:03 PM, Peter Maydell wrote:
>>> If an IOMMU supports mappings that care about the memory
>>> transaction attributes, then it no longer has a unique
>>> address -> o
On 22 May 2018 at 13:58, Auger Eric wrote:
> Hi Peter,
> On 05/21/2018 04:03 PM, Peter Maydell wrote:
>> If an IOMMU supports mappings that care about the memory
>> transaction attributes, then it no longer has a unique
>> address -> output mapping, but more than one. We can
>> represent these usi
Hi Peter,
On 05/21/2018 04:03 PM, Peter Maydell wrote:
> If an IOMMU supports mappings that care about the memory
> transaction attributes, then it no longer has a unique
> address -> output mapping, but more than one. We can
> represent these using an IOMMU index, analogous to TCG's
> mmu indexes.
On 22 May 2018 at 12:02, Peter Xu wrote:
> On Tue, May 22, 2018 at 09:40:44AM +0100, Peter Maydell wrote:
>> On 22 May 2018 at 04:03, Peter Xu wrote:
>> The reason for not just passing in the transaction attributes to
>> translate is that
>> (a) the iommu index abstraction makes the notifier setu
On Tue, May 22, 2018 at 09:40:44AM +0100, Peter Maydell wrote:
> On 22 May 2018 at 04:03, Peter Xu wrote:
> > On Mon, May 21, 2018 at 03:03:49PM +0100, Peter Maydell wrote:
> >> If an IOMMU supports mappings that care about the memory
> >> transaction attributes, then it no longer has a unique
> >
On 22 May 2018 at 04:03, Peter Xu wrote:
> On Mon, May 21, 2018 at 03:03:49PM +0100, Peter Maydell wrote:
>> If an IOMMU supports mappings that care about the memory
>> transaction attributes, then it no longer has a unique
>> address -> output mapping, but more than one. We can
>> represent these
On Mon, May 21, 2018 at 03:03:49PM +0100, Peter Maydell wrote:
> If an IOMMU supports mappings that care about the memory
> transaction attributes, then it no longer has a unique
> address -> output mapping, but more than one. We can
> represent these using an IOMMU index, analogous to TCG's
> mmu
If an IOMMU supports mappings that care about the memory
transaction attributes, then it no longer has a unique
address -> output mapping, but more than one. We can
represent these using an IOMMU index, analogous to TCG's
mmu indexes.
Signed-off-by: Peter Maydell
---
include/exec/memory.h | 52 +
20 matches
Mail list logo
