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

[Julien Grall <julien.grall@xxxxxxx>]

On 11/09/17 17:15, George Dunlap wrote:
> 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?
I think this would be fine.

Cheers,

--
Julien Grall

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