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

[Stefano Stabellini <sstabellini@xxxxxxxxxx>]

On Tue, 9 Feb 2021, Julien Grall wrote:
> 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...

I don't have an answer -- I hope nobody.


> > 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)...

I don't mean to insist as of course I accept the group decision and I
don't care about 4.12 that much (we don't use it as Xilinx). But this is
not about new hardware. This regression affects old hardware too. So yes
if an old Linux version worked on my HW I expect any of the slightly
newer (but still old) tarballs on kernel.org to work on the same HW.
That said I noticed that kernel.org seems to have only supported
releases on https://www.kernel.org/, while we have a mix.


> > 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.

Distinguishing between supported and not supported releases would be a
start. Maybe with a one line statement to recommend people to always use
supported (not just security-supported, fully supported) releases.