48-bit support in F26?

[Jon Masters]

Hi Jeremy, all,

I was just catching up with some folks and we discussed the status of
48-bit VA support. It seems to me that it would make most sense to have
an official coordination effort between those vendors/community members
who are interested, to ensure that they help with the necessary package
updates ahead of the kernel, and work with a test kernel to identify any
additional packages or issues that need resolving. I believe it would
make most sense to have a Fedora feature page (or something less grand,
but similar in concept) tracking this for F26, with the deps.

Perhaps Jeremy can update us on the status, and then he and others can
help drive this forward (someone should nominate themselves as the ring
leader too). I spoke with Cavium earlier today, and I know they'll be
keen to help. I know Qualcomm had expressed interest during our IRC
meetings in helping out. To that end, I'm copying at least those I know
so far who are interested here.

Jon.

[Josh Boyer]

On Wed, Sep 14, 2016 at 3:55 PM, Jon Masters  wrote:
> Hi Jeremy, all,
>
> I was just catching up with some folks and we discussed the status of
> 48-bit VA support. It seems to me that it would make most sense to have
> an official coordination effort between those vendors/community members
> who are interested, to ensure that they help with the necessary package
> updates ahead of the kernel, and work with a test kernel to identify any
> additional packages or issues that need resolving. I believe it would
> make most sense to have a Fedora feature page (or something less grand,
> but similar in concept) tracking this for F26, with the deps.

I would very much advocate for the full Feature page.  It will get the
change the appropriate attention technically, and it will raise
awareness of Aarch64 within Fedora from a general sense.

josh

[Jon Masters]

Great - that was my preference just didn't want to overkill it. But this sounds like good test run of doing the process the right way...

[Jeremy Linton]

Hi,
On 09/14/2016 02:55 PM, Jon Masters wrote:
> Hi Jeremy, all,

(trimming)
> Perhaps Jeremy can update us on the status, and then he and others can
> help drive this forward (someone should nominate themselves as the ring
> leader too). I spoke with Cavium earlier today, and I know they'll be
> keen to help. I know Qualcomm had expressed interest during our IRC
> meetings in helping out. To that end, I'm copying at least those I know
> so far who are interested here.

(this is the short version, even so, it got really long) <chuckle>

Right now, there are posted patches for 1.8.5, 17, 24 and 38 in the 
fedora mozjs defects 1242326, 1375305, 1375547. The 17, 24 and 38 
versions are fairly straightforward backports of the upstream mmap patch 
which maintains the mozjs ABI. The dependent packages should not need to 
be rebuilt. The 1.8.5 is based on an earlier patch and moves the tagging 
bits higher in the word and will require a further work to go beyond 
48-bit. That means that all js185 packages will need to be rebuilt 
against it. Doing it this way helps to solve some problems with couchdb.

There are public patches to move polkit (fedora bug #1375368, polkit bug 
#74592) to mozjs24 
(https://lists.freedesktop.org/archives/polkit-devel/2016-August/000503.html). 
That removes the mozjs17 dependency in fedora.

There are also public patches for libproxy 
https://github.com/libproxy/libproxy/pull/36, and pacrunner 
https://lists.01.org/pipermail/connman/2016-September/020902.html. To 
get them off js185.

Further, there is another effort to move 0ad off mozjs31 to mozj38. 
http://trac.wildfiregames.com/ticket/3708

This leaves couchdb, elinks, erlang, freewrl/libEIA, mediatomb and 
plowshare on js185.

At the moment, as far as mozjs is concerned I think its mostly working. 
The remaining js185 projects should work, but should have further 
attention. Erlang and freewrl are not trivial, and while it appears that 
freewrl was moving towards duktape, it doesn't actually appear to be 
working at the moment.

There is also a similar mess for lua, for which upstream version 2.1 has 
patches, but those need investigation and backporting for nginx/etc on 
fedora. Frankly, I'm trying to clear off my small piece of mozjs  before 
jumping into the lua bucket. If someone wants to grab that portion they 
are welcome to it.

I can provide more detail about specifics in mozjs if anyone is 
interested. My general goal right now is to consolidate on mozjs24 and 
mozjs38. If once that happens I will consider it done. If anyone decides 
to grab one of the projects let me know, I have partial (not yet 100% 
functional) reworks for a couple of them. Further, it should be noted 
that at least mozjs24 has regression failures on fedora/aarch64 at the 
moment. Those failures are not dependent on 48-bit.

js185:
couchdb-0:1.6.1-16.fc25.x86_64
elinks-0:0.12-0.48.pre6.fc24.x86_64
erlang-js-0:1.3.0-7.fc25.x86_64
freewrl-0:3.0.0-1.fc25.x86_64
js-devel-1:1.8.5-25.fc25.i686
js-devel-1:1.8.5-25.fc25.x86_64
libEAI-0:3.0.0-1.fc25.x86_64
libproxy-mozjs-0:0.4.12-4.fc25.x86_64
mediatomb-0:0.12.1-38.fc25.20120403gitb66dc1.x86_64
pacrunner-0:0.7-7.fc24.x86_64
plowshare-0:2.0.1-3.fc24.noarch

mozjs17:
mozjs17-devel-0:17.0.0-15.fc25.i686
mozjs17-devel-0:17.0.0-15.fc25.x86_64
polkit-0:0.113-5.fc24.x86_64

mozjs24:
cinnamon-0:3.0.6-1.fc25.x86_64
cjs-1:3.0.1-1.fc25.i686
cjs-1:3.0.1-1.fc25.x86_64
cjs-tests-1:3.0.1-1.fc25.x86_64
gjs-0:1.45.4-1.fc25.i686
gjs-0:1.45.4-1.fc25.x86_64
gjs-tests-0:1.45.4-1.fc25.x86_64
gnome-shell-0:3.21.4-1.fc25.x86_64
mozjs24-devel-0:24.2.0-8.fc24.i686
mozjs24-devel-0:24.2.0-8.fc24.x86_64

mozjs31:
0ad-0:0.0.20-4.fc25.x86_64 (in progress to 38

mozjs38:
mongodb-0:3.2.7-1.fc25.x86_64
mongodb-server-0:3.2.7-1.fc25.x86_64
mozjs38-devel-0:38.2.1-8.fc25.i686
mozjs38-devel-0:38.2.1-8.fc25

mozjs45:
(nothing at the moment, just in rawhide)

[Peter Lemenkov]

Hello All!

2016-09-14 23:59 GMT+02:00 Jeremy Linton :
> js185:
> couchdb-0:1.6.1-16.fc25.x86_64

...
> erlang-js-0:1.3.0-7.fc25.x86_64

I've got patches (mostly untested) for building erlang-js with mozjs170.

https://github.com/basho/erlang_js/pull/44#issuecomment-247323892

I'll take a look on CouchDB soon.

[Jeremy Linton]

On 09/15/2016 08:15 AM, Peter Lemenkov wrote:
> Hello All!
>
> 2016-09-14 23:59 GMT+02:00 Jeremy Linton :
> > js185:
> > couchdb-0:1.6.1-16.fc25.x86_64
>
> ...
> > erlang-js-0:1.3.0-7.fc25.x86_64
>
> I've got patches (mostly untested) for building erlang-js with mozjs170.
>
> https://github.com/basho/erlang_js/pull/44#issuecomment-247323892

Hi Peter,

I've been submitting patches to pull everything forward to at least 
mozjs24 which is where gnome/etc are. Would it be possible to push from 
17 to 24, because if erlang lands on mozjs17 when polkit gets moved to 
24, then again mozjs17 will have a single dependency in fedora.

That said, it looks like gnome are trying to move again, but they are 
too moving to mozjs31, just as 0ad leaves it.

[Jon Masters]

On 09/21/2016 02:47 PM, Jeremy Linton wrote:
> On 09/15/2016 08:15 AM, Peter Lemenkov wrote:
> > Hello All!
> >
> > 2016-09-14 23:59 GMT+02:00 Jeremy Linton :
> > > js185:
> > > couchdb-0:1.6.1-16.fc25.x86_64
> >
> > ...
> > > erlang-js-0:1.3.0-7.fc25.x86_64
> >
> > I've got patches (mostly untested) for building erlang-js with mozjs170.
> >
> > https://github.com/basho/erlang_js/pull/44#issuecomment-247323892
>
> Hi Peter,
>
> I've been submitting patches to pull everything forward to at least
> mozjs24 which is where gnome/etc are. Would it be possible to push from
> 17 to 24, because if erlang lands on mozjs17 when polkit gets moved to
> 24, then again mozjs17 will have a single dependency in fedora.
>
> That said, it looks like gnome are trying to move again, but they are
> too moving to mozjs31, just as 0ad leaves it.

Any chance you can wire up a feature page for F26 with this in it?

Going forward, I would /also/ like to be 52-bit VA tolerant. I realized
that since ARMv8.2 is now public, we can at least discuss on this list
that longer term there might be some server systems needing 52-bit
support as well (which is optional, so it'll depend upon cleaver kernel
enablement - likely with a optional 4th page directory that
transparently folds onto the pud or something) so we should at least
make sure we're tolerant toward that later on.

Jon.

[Peter Lemenkov]

2016-09-21 20:47 GMT+02:00 Jeremy Linton :
> On 09/15/2016 08:15 AM, Peter Lemenkov wrote:
> > Hello All!
> >
> > 2016-09-14 23:59 GMT+02:00 Jeremy Linton :
> > > js185:
> > > couchdb-0:1.6.1-16.fc25.x86_64
> >
> > ...
> > > erlang-js-0:1.3.0-7.fc25.x86_64
> >
> > I've got patches (mostly untested) for building erlang-js with mozjs170.
> >
> > https://github.com/basho/erlang_js/pull/44#issuecomment-247323892
>
> Hi Peter,
>
> I've been submitting patches to pull everything forward to at least mozjs24
> which is where gnome/etc are. Would it be possible to push from 17 to 24,
> because if erlang lands on mozjs17 when polkit gets moved to 24, then again
> mozjs17 will have a single dependency in fedora.

Working on it. The main issue is that they switched to C++, as well as
API change. I've got a version which compiles but segfaults during the
unit-tests.
> That said, it looks like gnome are trying to move again, but they are too
> moving to mozjs31, just as 0ad leaves it.

Mozjs versions zoo is a mess :)
Still better than v8 API as I was told :)

[Jeremy Linton]

Hi,

On 09/22/2016 04:58 AM, Peter Lemenkov wrote:
> 2016-09-21 20:47 GMT+02:00 Jeremy Linton :
> > On 09/15/2016 08:15 AM, Peter Lemenkov wrote:
> > > Hello All!
> > >
> > > 2016-09-14 23:59 GMT+02:00 Jeremy Linton :
> > > > js185:
> > > > couchdb-0:1.6.1-16.fc25.x86_64
> > >
> > > ...
> > > > erlang-js-0:1.3.0-7.fc25.x86_64
> > >
> > > I've got patches (mostly untested) for building erlang-js with mozjs170.
> > >
> > > https://github.com/basho/erlang_js/pull/44#issuecomment-247323892
> >
> > Hi Peter,
> >
> > I've been submitting patches to pull everything forward to at least mozjs24
> > which is where gnome/etc are. Would it be possible to push from 17 to 24,
> > because if erlang lands on mozjs17 when polkit gets moved to 24, then again
> > mozjs17 will have a single dependency in fedora.
>
> Working on it. The main issue is that they switched to C++, as well as
> API change. I've got a version which compiles but segfaults during the
> unit-tests.

I don't see that in the github repo, but moving from 17->24 is 
straightforward once you get the C++ compile/link conversions 
straightend out. The one gocha, which i'm guessing is biting you, is any 
calls to JS_NewCompartmentAndGlobalObject() need to be converted to 
JS_NewGlobalObject() then you need to construct an JSAutoCompartment and 
track it for the lifetime of the GlobalObject (or go ahead and try to 
use RAII, but that likely requires higher level restructing of the old C 
code). The auto compartment stuff caused me some grief when I initially 
ported polkit.
> > That said, it looks like gnome are trying to move again, but they are too
> > moving to mozjs31, just as 0ad leaves it.
>
> Mozjs versions zoo is a mess :)
> Still better than v8 API as I was told :)

[Peter Lemenkov]

2016-09-15 15:15 GMT+02:00 Peter Lemenkov :
> Hello All!
>
> 2016-09-14 23:59 GMT+02:00 Jeremy Linton :
> > js185:
> > couchdb-0:1.6.1-16.fc25.x86_64
>
> ...
> > erlang-js-0:1.3.0-7.fc25.x86_64
>
> I've got patches (mostly untested) for building erlang-js with mozjs170.

A short update on that - I've just updated erlang-js to build against
mozjs24. So one TODO item is completed.
> https://github.com/basho/erlang_js/pull/44#issuecomment-247323892
>
> I'll take a look on CouchDB soon.
>
> --
> With best regards, Peter Lemenkov.