Re: [Xen-devel] [PATCH RFC] Add SUPPORT.md

[George Dunlap <george.dunlap@xxxxxxxxxx>]

On 09/11/2017 04:54 PM, Julien Grall wrote:
> Hi,
> 
> Sorry I missed e-mail. It seems I was not CCed on it.

Sorry -- already had a pretty large CC list.  I'll add you for the next one.


>>>> +### ARM/SMMU
>>>> +
>>>> +    Status: Supported, with caveats
>>>> +
>>>> +Only ARM SMMU hardware is supported; non-ARM SMMU hardware is not
>>>> supported.
>>>
>>> I'm not sure of the purpose of this sentence, it's quite clear that
>>> the SMMU is only supported if available. Also, I'm not sure this
>>> should be spelled out in this document, x86 doesn't have a VT-d or SVM
>>> section.
>>
>> As George wrote, there are many SMMUs in the market for ARM based
>> platforms, not all of them of ARM design.
> 
> Few remarks here.
> 
> Firstly, what do you mean by Arm design? Is it spec compliant (i.e
> SMMUv1, SMMUv2, SMMUv3) ? Or is it implementation coming from Arm
> (SMMU-400, SMMU-401, SMMU-500,...)?

Well as you and Stefano are going to be primarily doing security
support, I think whatever you think is most reasonable for you to
support, and whatever communicates best to your users what functionality
actually works and what will be security supported.

> At the moment we have no support of SMMUv3 at all (this would be a
> separate driver as the spec is very different).
> 
> Regarding SMMUv1 and SMMUv2. Technically we should support all SMMUs
> which are compliant with the spec, providing there are no workaround
> necessary (yes there are some hardware only 99.9% compliant).
> 
> But, we can't even claim that we support Arm implementation. At least
> SMMU-401 (used by Seattle and Versatile Express) is not supported.
> 
> Furthermore, Arm may release new IP in the future. Does it mean we
> support them by default?
> 
> So there are some clarifications needed on what we actually support.
> 
> If we decide the support status is based on hardware, then it raise the
> questions on what about other specifications (e.g GICv2, GICv3, GICv4)?
> Each vendor is free to provide its own implementation (not necessarily
> bug free and fully compliant).

On the whole it sounds like we ought to have separate stanzas for SMMUv1
and SMMUv2.

I'd say focus on accurately implementing the spec.  Call out specific
non-compliant implementations as and when you feel like you need to be
specific.

Shall I make this:

---
### ARM/SMMUv1

    Status: Supported

### ASM/SMMUv2

    Status: Supported
---

Will that communicate effectively that you only support ARM-spec SMMUs?
Or do we need to add some extra verbiage to make sure people know that
non-ARM specs are not supported?

 -George

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
https://lists.xen.org/xen-devel