From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Andrew Cooper <andrew.cooper3@citrix.com>
Cc: Stefano Stabellini <sstabellini@kernel.org>,
Wei Liu <wei.liu2@citrix.com>,
George Dunlap <George.Dunlap@eu.citrix.com>,
Tim Deegan <tim@xen.org>, Jan Beulich <JBeulich@suse.com>,
xen-devel <xen-devel@lists.xenproject.org>,
Ian Jackson <ian.jackson@citrix.com>
Subject: Re: [PATCH v2 0/3] Remove tmem
Date: Wed, 2 Jan 2019 12:27:13 -0500 [thread overview]
Message-ID: <20190102172713.GA23427@char.us.oracle.com> (raw)
In-Reply-To: <7c1a8584-9b32-86b9-9154-932089d807cb@citrix.com>
On Mon, Dec 31, 2018 at 12:43:39PM +0000, Andrew Cooper wrote:
> On 03/12/2018 09:56, Jan Beulich wrote:
> >>>> On 30.11.18 at 19:01, <wei.liu2@citrix.com> wrote:
> >> On Fri, Nov 30, 2018 at 05:09:42PM +0000, Ian Jackson wrote:
> >>> Wei Liu writes ("[PATCH v2 0/3] Remove tmem"):
> >>>> It is agreed that tmem can be removed from xen.git. See the thread starting
> >>
> >>
> >>>> from <D5E866B2-96F4-4E89-941E-73F578DF2F17@citrix.com>.
> >>> Those are notes from some phone call amongst industry stakeholders.
> >>> None of the messages have a Subject line mentioning tmem. There is no
> >>> explanation of the basis for the decision; just a confirmation from
> >>> the current maintainers that they will ack the removal.
> >>>
> >>> I think this is not really an appropriate way to carry on! What if
> >>> there is someone else who wants to step up to maintain this ? What
> >>> about user communication ? Going straight from `Supported' to
> >>> `Deleted' seems rather vigorous.
> >> Step up to maintain> I would rather say step up to develop.
> >>
> >> The status in MAINTAINERS is wrong. According to SUPPORT.md, it is only
> >> experimental. Our definition of "experimental" is:
> >>
> >> Functional completeness: No
> >> Functional stability: Here be dragons
> >> Interface stability: Not stable
> >> Security supported: No
> > Exactly. Plus my proposal to remove it was posted to xen-devel
> > on Aug 30th. I don't think removal of an experimental feature
> > requires posting to xen-announce. Ian - please reconsider your
> > nack.
>
> I concur with Wei and Jan. TMEM has been off by default due to being
> declared "full of security holes - don't use" since XSA-15. That was in
> 2012, and TMEM hasn't made its way back into security support in that time.
>
> In addition, it was never fixed to work with Migration v2. The save
> side doesn't query any TMEM state, and convert-legacy-stream raises TODO
> on encountering legacy TMEM data.
>
> I don't know about other distributions, but it has been compiled out of
> XenServer for all versions which have Kconfig.
>
> tl;dr It doesn't work, and at this point, it looks very unlikely to
> change. There is a non-zero cost for retaining obsolete functionality,
> and the hypervisor maintainers want it gone in 4.12, which we think is
> entirely reasonable given the circumstances.
I agree on all counts. Can we please remove it?
>
> ~Andrew
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
next prev parent reply other threads:[~2019-01-02 17:27 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-11-28 13:58 [PATCH v2 0/3] Remove tmem Wei Liu
2018-11-28 13:58 ` [PATCH v2 1/3] tools: remove tmem code and commands Wei Liu
2018-11-30 17:10 ` Ian Jackson
2018-11-28 13:58 ` [PATCH v2 2/3] xen: remove tmem from hypervisor Wei Liu
2018-11-28 14:43 ` Jan Beulich
2018-11-28 14:47 ` Wei Liu
2018-11-28 14:50 ` Wei Liu
2018-11-28 15:49 ` Daniel De Graaf
2018-11-28 13:58 ` [PATCH v2 3/3] docs: remove tmem related text Wei Liu
2018-11-28 15:49 ` Daniel De Graaf
2018-11-29 2:50 ` [PATCH v2 0/3] Remove tmem Konrad Rzeszutek Wilk
2018-11-29 11:42 ` Wei Liu
2018-11-30 17:09 ` Ian Jackson
2018-11-30 18:01 ` Wei Liu
2018-12-03 9:56 ` Jan Beulich
2018-12-31 12:43 ` Andrew Cooper
2019-01-02 17:27 ` Konrad Rzeszutek Wilk [this message]
2019-03-12 12:21 ` Wei Liu
2019-03-12 13:04 ` Jan Beulich
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20190102172713.GA23427@char.us.oracle.com \
--to=konrad.wilk@oracle.com \
--cc=George.Dunlap@eu.citrix.com \
--cc=JBeulich@suse.com \
--cc=andrew.cooper3@citrix.com \
--cc=ian.jackson@citrix.com \
--cc=sstabellini@kernel.org \
--cc=tim@xen.org \
--cc=wei.liu2@citrix.com \
--cc=xen-devel@lists.xenproject.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.