System management messages in AMD IOMMU

[Valentine Sinitsyn]

Hi everybody,

AMD IOMMU device table entries provide some controls over system
management messages, snooping and other stuff I believe is
HyperTransport-specific (see Sect. 2.2.2.1). Am I right that we can just
disable (i.e. target-abort incoming request) all of these when filling
DTE iommu_add_cpi_device()?

A second question is if we should permit access to I/O space from
peripheral devices. I never saw it in the wild and again have rather
vague idea of what it is.

Thanks,
Valentine

[Jan Kiszka]

On 2015-04-15 07:27, Valentine Sinitsyn wrote:
> Hi everybody,
>
> AMD IOMMU device table entries provide some controls over system
> management messages, snooping and other stuff I believe is
> HyperTransport-specific (see Sect. 2.2.2.1). Am I right that we can just
> disable (i.e. target-abort incoming request) all of these when filling
> DTE iommu_add_cpi_device()?

Yep, that was the conclusion for a first approach. None of the devices
we currently control via an IOMMU should have a need to send SMIs.

>
> A second question is if we should permit access to I/O space from
> peripheral devices. I never saw it in the wild and again have rather
> vague idea of what it is.

Huh? That exists? I would go for disabling this as well.

How does Linux' IOMMU handle these cases?

Jan

--
Siemens AG, Corporate Technology, CT RTC ITP SES-DE
Corporate Competence Center Embedded Linux

[Valentine Sinitsyn]

Hi Jan,

Thanks for replying.

On 15.04.2015 10:37, Jan Kiszka wrote:
> On 2015-04-15 07:27, Valentine Sinitsyn wrote:
>> Hi everybody,
>>
>> AMD IOMMU device table entries provide some controls over system
>> management messages, snooping and other stuff I believe is
>> HyperTransport-specific (see Sect. 2.2.2.1). Am I right that we can just
>> disable (i.e. target-abort incoming request) all of these when filling
>> DTE iommu_add_cpi_device()?
>
> Yep, that was the conclusion for a first approach. None of the devices
> we currently control via an IOMMU should have a need to send SMIs.

Yes, I remember we discussed SMI and decided to ban them (in fact, it's
already done). However, I feel these system management messages refer to
something else. See quote below:

> system management message enable. Specifies whether device-initiated untrans-
> lated memory requests that target the system management address space
> (FD_F910_0000h to FD_F910_FFFFh) are blocked, forwarded, or
translated by the IOMMU.
...
> 01b=Device initiated system management messages, including INTx messages, are for-
> warded untranslated by the IOMMU. Upstream reads or non-posted writes return target
> abort status. Translation requests return target abort status.

Frankly I don't fully understand INTx in this context.

>> A second question is if we should permit access to I/O space from
>> peripheral devices. I never saw it in the wild and again have rather
>> vague idea of what it is.
>
> Huh? That exists? I would go for disabling this as well.
>
> How does Linux' IOMMU handle these cases?

Haven't checked yet, but thanks for the idea.

Valentine

[Jan Kiszka]

Hmm, have to read up on this I guess. But we could also look at this
from another perspective: only allow device to send messages that we
already allow with VT-d, and that's just APIC fixed-mode and lowest-prio
IIRC.

[Valentine Sinitsyn]

Yup, I also decided to set for fixed and arbitrated interrupt (unmapped,
at the first step) and see what happens.

Valentine