Re: [PATCH v2] xen/arm: fix gnttab_need_iommu_mapping

[Julien Grall <julien.grall.oss@xxxxxxxxx>]

On Tue, 9 Feb 2021 at 17:31, Stefano Stabellini <sstabellini@xxxxxxxxxx> wrote:
>
> On Tue, 9 Feb 2021, Ian Jackson wrote:
> > Jan Beulich writes ("Re: [PATCH v2] xen/arm: fix 
> > gnttab_need_iommu_mapping"):
> > > On 08.02.2021 21:24, Stefano Stabellini wrote:
> > ...
> > > > For these cases, I would just follow a simple rule of thumb:
> > > > - is the submitter willing to provide the backport?
> > > > - is the backport low-risk?
> > > > - is the underlying bug important?
> > > >
> > > > If the answer to all is "yes" then I'd go with it.
> > >
> > > Personally I disagree, for the very simple reason of the question
> > > going to become "Where do we draw the line?" The only non-security
> > > backports that I consider acceptable are low-risk changes to allow
> > > building with newer tool chains. I know other backports have
> > > occurred in the past, and I did voice my disagreement with this
> > > having happened.
> >
> > I think I take a more relaxed view than Jan, but still a much more
> > firm line than Stefano.  My opinion is that we should make exceptions
> > for only bugs of exceptional severity.
> >
> > I don't think I have seen an argument that this bug is exceptionally
> > severe.
> >
> > For me the fact that you can only experience this bug if you upgrade
> > the hardware or significantly change the configuration, means that
> > this isn't so serious a bug.
>
> Yeah, I think that's really the core of this issue. If somebody is
> already using 4.12 happily, there is really no reason for them to take
> the fix. If somebody is about to use 4.12, then it is a severe issue.

If somebody is about to use 4.12, then it is most likely going to
encounter a serious blocker as there is no support for generic SMMU
bindings. I would be surprised if there are a lot of DT still using
the old bindings, at which point such users would want to switch to
4.15 + your patches to add support.

>
> The view of the group is that nobody should be switching to 4.12 now
> because there are newer releases out there. I don't know if that is
> true.

This is mostly based on the definition of supported vs security
supported. When a tree is only security supported, then there is no
promise the code will run on any systems.

>
> I didn't realize we had a policy or even a recommendation of always
> choosing the latest among the many releases available with
> security-support. I went through the website and SUPPORT.md but couldn't
> find it spelled out anywhere. See:

May I ask, what sort of users would want to start a
development/product based on a soon to be abandoned version?

For any new development, I have always advised to switch to the latest
Xen (or at least stable) because it will contain the latest fixes,
features, and better support because the code is still in mind...

>
> https://xenproject.org/downloads/
> https://xenproject.org/downloads/xen-project-archives/xen-project-4-12-series/
> https://xenbits.xen.org/gitweb/?p=xen.git;a=blob;f=SUPPORT.md;h=52f25fa85af41fa3b38288ab7e172408b77dc779;hb=97b7b5567fba6918a656ad349051b5343b5dea2e
>
> At most we have:
>
>     Supported-Until: 2020-10-02
>     Security-Support-Until: 2022-04-02
>
> Anecdotally, if I go to https://www.kernel.org/ to download a kernel
> tarball, I expect all tarballs to have all the major functionalities. I
> wouldn't imagine that I cannot get one entire Linux subsystem (e.g.
> ethernet or SATA) to work if I don't pick the latest.

I think this is an unrealistic expectation... You can't pick any
version of stable Linux and expect it to work on your shiny HW. There
might be missing drivers, workaround (including in core subsystems)...

>
> Maybe it would make sense to clarify which releases are discouraged from
> being used on https://xenproject.org/downloads/ at least?

Feel free to suggest a wording that can be discussed here.

Cheers,