Re: [PATCH 00/36] AArch64 Linux kernel port

[Catalin Marinas]

On Fri, Jul 06, 2012 at 10:05:41PM +0100, Catalin Marinas wrote:
> This set of patches implements the core Linux support for the AArch64
> (64-bit ARM) architecture.
...
> These patches are also available on this branch:
> 
> git://git.kernel.org/pub/scm/linux/kernel/git/cmarinas/linux-aarch64.git 
> upstream

Just an update - the 'master' branch in the above Git tree contains the
latest changes following the feedback received so far (and it's not
rebased). The 'upstream' branch has the individual patches as they will
be posted on LKML (it may be rebased). The trees are updated to 3.5.

The Linux port directory has been renamed to arch/arm64/.

I'll be on holiday from tomorrow for nearly two weeks with little access
to email. I plan to post version 2 of the series when I get back, most
likely based on 3.6-rc1.

-- 
Catalin
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 00/36] AArch64 Linux kernel port

[Guillem Jover]

On Sat, 2012-07-07 at 19:27:12 +, Arnd Bergmann wrote:
> On Saturday 07 July 2012, Olof Johansson wrote:
> > > ARM introduced AArch64 as part of the ARMv8 architecture
> > 
> > With the risk of bikeshedding here, but I find the name awkward. How
> > about just naming the arch port arm64 instead? It's considerably more
> > descriptive in the context of the kernel.  For reference, we didn't
> > name ppc64, nor powerpc, after what the IBM/power.org marketing people
> > were currently calling the architecture at the time either.
> 
> I agree the name sucks, and I'd much prefer to just call it arm64
> as well. The main advantage of the aarch64 name is that it's the
> same as the identifier in the elf triplet, and it makes sense to
> keep the same name for all places where we need to identify the
> architecture. This also includes the rpm and dpkg architecture names,
> and the string returned by the uname syscall. If everything else
> is aarch64, we should use that in the kernel directory too, but
> if everyone calls it arm64 anyway, we should probably use that name
> for as many things as possible.

FWIW the dpkg architecture name will be arm64:



And I'd be happy to change the GNU triplet match in dpkg, if someone
considered trying to get it renamed to something less unfortunate.

thanks,
guillem
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 00/36] AArch64 Linux kernel port

[Linus Torvalds]

On Wed, Jul 18, 2012 at 12:35 PM, Jon Masters  wrote:
>
> So we should think with a
> mindset of 2-3 years from now rather than where we were yesterday.

Why do you think aarch64 would be a better name 2-3 years from now?

And why do you think ARM management magically has good taste? They got
the PAE thing wrong too. They literally copied everything Intel did
*wrong* in this area, and we know it was wrong even with *more* than
2-3 years of hind-sight.

 "the one who does not remember history is bound to live through it again"
- Santayana

Seriously. We've gone through exactly this on the x86 side. Your "I'm
sure it will be better in 2-3 years" has nothing to back it up. And
no, stupid marketing decisions by companies do *not* suddenly turn out
to be smart things a few years later.

  Linus
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 00/36] AArch64 Linux kernel port

[Jon Masters]

On 07/18/2012 01:14 PM, Catalin Marinas wrote:

> Debian has different names for the architecture and compiler triplet:
> amd64 with x86_64-linux-gnu, similar for x32. None of these match the
> arch/x86/ Linux directory. Even if there is some confusion initially, it
> will go away in a relatively short time (if not ARM can sponsor a water
> drinking event ;).

Sign me up for the water drinking. I'll also take ARM branded Kool-Aid,
though it's been argued that I've already found a good dose of that.

You make a good point, Catalin. Aside from arguing over the name, we
should bear in mind that ARM management have made some decisions around
AArch64 and I suspect as it starts to appear in more use, there will be
less confusion. It's early now. There is no silicon out there for us to
use at this point in the process, etc. etc. So we should think with a
mindset of 2-3 years from now rather than where we were yesterday.

Jon.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 00/36] AArch64 Linux kernel port

[Måns Rullgård]

Catalin Marinas  writes:

> On Wed, Jul 18, 2012 at 04:27:12PM +0100, Dennis Gilmore wrote:
>> El Tue, 17 Jul 2012 22:33:33 -0400
>> Jon Masters  escribió:
>> > On 07/17/2012 06:35 PM, Joe Perches wrote:
>> > > On Tue, 2012-07-17 at 23:18 +0100, Catalin Marinas wrote:
>> > > 
>> > >> The uname will still report
>> > >> "aarch64" to match the compiler triplet and also avoid confusion of
>> > >> existing 32-bit ARM scripts that simply check for "arm*" in the
>> > >> machine name.
>> 
>> that means that the yum base arch will need to be aarch64 and the arch
>> used in rpm will be aarch64 also. its throwing something weird and
>> confusing right in the face of users. I urge you to change it all to
>> arm64 just changing the directory in the kernel is pointless as it still
>> exposes all the weirdness of the name to users and will result in a
>> large amount of education and a constant stream of the same question
>> "Where do i find the arm64 bits?" until such time as the users learn
>> that arm64 is aarch64. All the tooling uses "uname -m" to determine the
>> package architecture.
>
> The directory name change is just to avoid some word duplication in
> arch/aarch64/. It can be a64 (as per the ISA) or aa64 or whatever else.
> The "arm64" got most votes so far. I still prefer "aarch64" for
> consistency but I'm can change the directory name, it doesn't matter
> much.
>
> As for the "aarch64" name, whether we like it were not, it was chosen by
> ARM Ltd to describe the new execution mode. It is one of the few
> constants in the changing world of architecture versions and CPU
> numbers. It's also a clear separation from the multitude of ARM* names
> which I agree, is confusing (and, BTW, we had ARM6 processors as well).
>
> People that have been involved with this architecture don't find the
> name impossible (and not all of them are based in Cambridge ;). It may
> not be as aesthetic and easy to pronounce as "arm64" but you get used to
> it. I personally find it easier to pronounce (and type) than "x86_64".
>
> Just to be clear, I'm not trying to defend the "beauty" of this name (I
> have my own opinion) but we spend too much time arguing about it. This
> name has implications beyond the technical arguments of some script or
> another and it will be found in all the technical documents produced by
> ARM Ltd (including the next ARM Architecture Reference Manual).

Maybe it would help if someone explained _why_ the aarch64 name was
chosen.  Assuming it wasn't handed down by a supreme being, there has
to be some reasoning behind the choice.

-- 
Måns Rullgård
m...@mansr.com
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 00/36] AArch64 Linux kernel port

[Catalin Marinas]

On Wed, Jul 18, 2012 at 04:27:12PM +0100, Dennis Gilmore wrote:
> El Tue, 17 Jul 2012 22:33:33 -0400
> Jon Masters  escribió:
> > On 07/17/2012 06:35 PM, Joe Perches wrote:
> > > On Tue, 2012-07-17 at 23:18 +0100, Catalin Marinas wrote:
> > > 
> > >> The uname will still report
> > >> "aarch64" to match the compiler triplet and also avoid confusion of
> > >> existing 32-bit ARM scripts that simply check for "arm*" in the
> > >> machine name.
> 
> that means that the yum base arch will need to be aarch64 and the arch
> used in rpm will be aarch64 also. its throwing something weird and
> confusing right in the face of users. I urge you to change it all to
> arm64 just changing the directory in the kernel is pointless as it still
> exposes all the weirdness of the name to users and will result in a
> large amount of education and a constant stream of the same question
> "Where do i find the arm64 bits?" until such time as the users learn
> that arm64 is aarch64. All the tooling uses "uname -m" to determine the
> package architecture.

The directory name change is just to avoid some word duplication in
arch/aarch64/. It can be a64 (as per the ISA) or aa64 or whatever else.
The "arm64" got most votes so far. I still prefer "aarch64" for
consistency but I'm can change the directory name, it doesn't matter
much.

As for the "aarch64" name, whether we like it were not, it was chosen by
ARM Ltd to describe the new execution mode. It is one of the few
constants in the changing world of architecture versions and CPU
numbers. It's also a clear separation from the multitude of ARM* names
which I agree, is confusing (and, BTW, we had ARM6 processors as well).

People that have been involved with this architecture don't find the
name impossible (and not all of them are based in Cambridge ;). It may
not be as aesthetic and easy to pronounce as "arm64" but you get used to
it. I personally find it easier to pronounce (and type) than "x86_64".

Just to be clear, I'm not trying to defend the "beauty" of this name (I
have my own opinion) but we spend too much time arguing about it. This
name has implications beyond the technical arguments of some script or
another and it will be found in all the technical documents produced by
ARM Ltd (including the next ARM Architecture Reference Manual).

> The triplet that fedora will use will be preferred
> arm64-redhat-linux-gnu or aarch64-redhat-linux-gnu

Gcc already went for aarch64-*. I really doubt they are willing to
change it but you can try.

> but again aarch64 will propogate to a lot of highly visible places
> where it will just cause undue confusion.

Debian has different names for the architecture and compiler triplet:
amd64 with x86_64-linux-gnu, similar for x32. None of these match the
arch/x86/ Linux directory. Even if there is some confusion initially, it
will go away in a relatively short time (if not ARM can sponsor a water
drinking event ;).

-- 
Catalin
(really thirsty ;)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 00/36] AArch64 Linux kernel port

[Dennis Gilmore]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

El Tue, 17 Jul 2012 22:33:33 -0400
Jon Masters  escribió:
> On 07/17/2012 06:35 PM, Joe Perches wrote:
> > On Tue, 2012-07-17 at 23:18 +0100, Catalin Marinas wrote:
> > 
> >> The uname will still report
> >> "aarch64" to match the compiler triplet and also avoid confusion of
> >> existing 32-bit ARM scripts that simply check for "arm*" in the
> >> machine name.

that means that the yum base arch will need to be aarch64 and the arch
used in rpm will be aarch64 also. its throwing something weird and
confusing right in the face of users. I urge you to change it all to
arm64 just changing the directory in the kernel is pointless as it still
exposes all the weirdness of the name to users and will result in a
large amount of education and a constant stream of the same question
"Where do i find the arm64 bits?" until such time as the users learn
that arm64 is aarch64. All the tooling uses "uname -m" to determine the
package architecture.

The triplet that fedora will use will be preferred
arm64-redhat-linux-gnu or aarch64-redhat-linux-gnu

but again aarch64 will propogate to a lot of highly visible places
where it will just cause undue confusion.  adding a extra check for
arm64* before arm* if that is what people are using will not be hard to
do.

> > The compiler triplet seems trivial to change.
> > 
> > The other bit is a relatively weak argument as the 32bit arm
> > scripts can be changed or fixed likely just as easily.
> 
> There's a surprising amount of assumption out there around what arm*
> means (or doing wildcard matches liberally). I'm glad (from the point
> of view of a distribution bootstrap) that we don't have to worry
> about that aspect of getting AArch64 support up and running. The
> directory name is just that - a name - and unimportant. I like
> aarch64 from the point of view of distinguishing "this is not ARM,
> no, it's not just an extension, and no it's not just two numbers
> different or wider regs", but it seems fairly inevitable that it's
> going to be arch/arm64. The main thing is that we understand this
> isn't like i686->x86_64.

autoconf etc checks for " arm-*  | armbe-* | armle-* | armeb-* |
armv*-* "  arm64-* will not match the existing regexs in common
use. configure scripts will need rebuilding regardless of if its
aarch64 or arm64 to me the argument that  arm64 will catch existing
scripts is extremely weak. especially when the first target is really
almost completely new for arm in the server market.

Dennis
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.18 (GNU/Linux)

iEYEARECAAYFAlAG1dMACgkQkSxm47BaWfdzRQCfUdBHeLoDDC2yJTOxdMP0k0ej
GcMAoKoRXG6d7xOvhPDbh3p4J8lKHYpb
=KXum
-END PGP SIGNATURE-
N�r��yb�X��ǧv�^�)޺{.n�+{zX����ܨ}���Ơz�&j:+v���zZ+��+zf���h���~i���z��w���?�&�)ߢf��^jǫy�m��@A�a���
0��h���i

Re: [PATCH 00/36] AArch64 Linux kernel port

[Catalin Marinas]

Hi Jon,

On Wed, Jul 18, 2012 at 06:35:40AM +0100, Jon Masters wrote:
> On 07/06/2012 05:05 PM, Catalin Marinas wrote:
> 
> > These patches are also available on this branch:
> > 
> > git://git.kernel.org/pub/scm/linux/kernel/git/cmarinas/linux-aarch64.git 
> > upstream
> 
> What's your general plan for tracking development with this branch?

The "upstream" branch is rebased according to the feedback I receive and
it will match the patches that I post on LKML.

For development, the "master" branch on that tree is never rebased, so
you can see the changes added since the first version (currently only
two published). It is however kept in sync with the rebased branch (so
there shouldn't be any diff between them).

Both of them will track the latest mainline (though not daily).

-- 
Catalin
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 00/36] AArch64 Linux kernel port

[Jon Masters]

On 07/06/2012 05:05 PM, Catalin Marinas wrote:

> These patches are also available on this branch:
> 
> git://git.kernel.org/pub/scm/linux/kernel/git/cmarinas/linux-aarch64.git 
> upstream

Catalin,

What's your general plan for tracking development with this branch?

Jon.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 00/36] AArch64 Linux kernel port

[Jon Masters]

On 07/17/2012 05:50 AM, Alan Cox wrote:
>> Right, I would say that with any CPU core more powerful than this one
>> or with more than a few of these, you will also have trouble coming
>> up with workloads that really require the CPU performance but don't
>> also require a 64 bit virtual address space in either user space
>> or kernel.
> 
> There are lots of them - soft radio for example can burn near infinite
> CPU resource depending upon the amount you are fishing out, but its pure
> throughput.

I think A15 is likely to be a good 32-bit story there. Performance wise,
it's awesome. The reason for 64-bit is both emotional ("real servers
must be 64-bit! "), and as an opportunity to
clean up lots of assumptions and have a standard base, but it's not the
end of the 32-bit story. I believe ARM have said many times that they're
not giving up on AArch32, and in fact, if you read the public ISA docs
you'll see additional 32-bit instructions in v8.

Jon.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 00/36] AArch64 Linux kernel port

[Jon Masters]

On 07/17/2012 06:35 PM, Joe Perches wrote:
> On Tue, 2012-07-17 at 23:18 +0100, Catalin Marinas wrote:
> 
>> The uname will still report
>> "aarch64" to match the compiler triplet and also avoid confusion of
>> existing 32-bit ARM scripts that simply check for "arm*" in the machine
>> name.
> 
> The compiler triplet seems trivial to change.
> 
> The other bit is a relatively weak argument as the 32bit arm
> scripts can be changed or fixed likely just as easily.

There's a surprising amount of assumption out there around what arm*
means (or doing wildcard matches liberally). I'm glad (from the point of
view of a distribution bootstrap) that we don't have to worry about that
aspect of getting AArch64 support up and running. The directory name is
just that - a name - and unimportant. I like aarch64 from the point of
view of distinguishing "this is not ARM, no, it's not just an extension,
and no it's not just two numbers different or wider regs", but it seems
fairly inevitable that it's going to be arch/arm64. The main thing is
that we understand this isn't like i686->x86_64.

Jon.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 00/36] AArch64 Linux kernel port

[Joe Perches]

On Tue, 2012-07-17 at 23:18 +0100, Catalin Marinas wrote:

> The uname will still report
> "aarch64" to match the compiler triplet and also avoid confusion of
> existing 32-bit ARM scripts that simply check for "arm*" in the machine
> name.

The compiler triplet seems trivial to change.

The other bit is a relatively weak argument as the 32bit arm
scripts can be changed or fixed likely just as easily.




--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 00/36] AArch64 Linux kernel port

[Catalin Marinas]

On Mon, Jul 16, 2012 at 12:53:21AM +0100, Linus Torvalds wrote:
> On Sun, Jul 15, 2012 at 4:21 PM, Måns Rullgård  wrote:
> >
> > FWIW, I'd prefer naming the directory either arm64 or armv8 for a few
> > reasons:
> >
> > - Those are the names people actually use to refer to the architecture
> > - They are more descriptive.
> > - I think the official name is rather silly.
> 
> Agreed on those three for arm64.
> 
> However, please don't use the *INSANE* ARM "v8" naming.

I agree, ARMv8 is not the right name to use in this situation. It doesn't
qualify whether the system is running in 32 or 64-bit mode. ARMv8 is the
name of the latest ARM architecture and we expect this number to go up
in the future. It introduces the new 64-bit execution mode with new
exception model and instruction set called AArch64. ARMv8 may also
support the 32-bit (AArch32) mode which is backwards compatible with the
ARMv7 architecture.

The AArch64 mode will most likely be found in future ARM architecture
versions, so breaking the link between the Linux port and the
architecture version is the right thing. For this reason, uname no
longer reports "armv*" in the 64-bit port but simply "aarch64" (for
compat tasks it still uses the old style). CPU features available to
user space are already advertised via the hwcap bits.

That said, the directory name of the Linux port does not have to match
the name of the architecture or execution mode (we had arch/arm26/ until
a few years ago). So I'm ok with renaming the directory to arch/arm64/,
together with the CONFIG_ARM64* symbols. The uname will still report
"aarch64" to match the compiler triplet and also avoid confusion of
existing 32-bit ARM scripts that simply check for "arm*" in the machine
name.

-- 
Catalin
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 00/36] AArch64 Linux kernel port

[Catalin Marinas]

Hi,

On Mon, Jul 16, 2012 at 01:16:51PM +0100, Pavel Machek wrote:
> > > > The AArch32 execution mode is optional, so it depends on the actual CPU
> > > > implementation (while AArch64 is mandatory). If the implementation
> > > > supports it, the most likely scenario for AArch32 at kernel level is in
> > > > virtual machines or the secure OS. I'll explain below why.
> > > > 
> > > > The exception (or privilege) levels on an ARMv8 architecture look like
> > > > this:
> > > > 
> > > > Secure WorldNormal World
> > > > +-+
> > > > | EL3 | - Secure monitor
> > > > +-+
> > > > +-+
> > > > | EL2 | - Hypervisor (normal world only)
> > > > +-+
> > > > +-+ +-+
> > > > | EL1 | | EL1 | - OS kernel (secure or normal)
> > > > +-+ +-+
> > > > +-+ +-+
> > > > | EL0 | | EL0 | - User apps (secure or normal)
> > > > +-+ +-+
> > > > 
> > > > In theory, each of these levels (implementation specific) can run both
> > > > AArch32 and AArch64 modes. There is however a restriction on how the
> > > > mode switching is done - this can only happen on a change of exception
> > > > level. When going up the EL the register width (RW) can never go down. A
> > > > lower EL can never have a higher RW than a higher EL.
> > > > 
> > > > Additionally, the RW (the AArch32/AArch64 mode) for an EL is controlled
> > > > by the next higher level (with EL3 hard-wired). An EL cannot cause
> > > > itself to switch between AArch32 and AArch64.
> > > 
> > > So is the highest level always hardwired to 64-bit on ARMv8?
> > 
> > If an implementation supports AArch32 at EL3 there could be some
> > physical (or some FPGA config) switch to choose between the two. But
> > since AArch64 is mandated, I don't see why one would force AArch32 at
> > EL3 and therefore all lower exception levels (and make a big part of the
> > processor unused).
> 
> Actually I see one ... and I can bet it will happen.
> 
> So you create that shiny new ARMv8 compliant CPU, 8 cores, 2GHz. HTC
> will want to use it with 1GB of RAM...

By the time we get ARMv8 silicon, 1GB RAM is no longer the norm. There
are smartphones as Galaxy S3 with this amount of RAM already.

> and put around exiting OMAP perihepals.

Such peripherals must be supported by code under drivers/. There is a
lot of work that Arnd and Olof are doing on the ARM SoC code, so even on
AArch32 a lot of this code is cleaned up.

> At that point they will have choice of either:
> 
> 1) going arm64, with no advantages and disadvantage of having to
> debug/stabilize arm64 kernel+toolchain (+hardware; yes, early 64bit
> hardware usually has security bugs), and to port the omap code from
> arch/arm to arch/arm64

We no longer accept platform code in the way that we had on 32-bit ARM
years ago. New platform code must follow strict rules on AArch32 already
and on AArch64 we ask for even more standardisation together with single
kernel image by default. With a standard booting protocol and CPU power
management, FDT and the peripherals code into drivers/ there isn't much
(if any) left for the arch code.

> 2) just putting that 8 cores into arm32 mode. Yes, a bit of silicion
> is unused. But if the ARMv8 has most cores/biggest performance, it
> still makes sense, and 32bits is inherently faster due to pointers
> being smaller.

One of the key aspects that ARM partners try to achieve is lower power.
They would not go for an ARMv8 unless they need 64-bit processing. Even
if half of the core is not used, it still uses power (leakage) that
would drain the battery.

If one needs bigger physical address space now, there is Cortex-A15
already.

-- 
Catalin
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 00/36] AArch64 Linux kernel port

[Alan Cox]

> Right, I would say that with any CPU core more powerful than this one
> or with more than a few of these, you will also have trouble coming
> up with workloads that really require the CPU performance but don't
> also require a 64 bit virtual address space in either user space
> or kernel.

There are lots of them - soft radio for example can burn near infinite
CPU resource depending upon the amount you are fishing out, but its pure
throughput.

Alan
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 00/36] AArch64 Linux kernel port

[Arnd Bergmann]

On Tuesday 17 July 2012, Christoph Hellwig wrote:
> On Sun, Jul 15, 2012 at 07:43:07PM +, Arnd Bergmann wrote:
> > Yes, I agree that's the best way to handle this. Compared to other
> > architectures, I think x86 is the only that allows booting either a
> > 32 or 64 bit kernel on the same system. We used to support 32 bit
> > kernels on 64 bit PowerMac, but nobody used it and we discontinued
> > it long ago. Tile 64 bit is actually incompatible with 32 bit kernels
> > at the architecture level and would require a third mode. On sparc,
> > parisc and mips, AFAIK we could support 32 bit kernels on 64 bit
> > machines, but never did.
> 
> On mips it works just fine.  On Sparc I don't think Linux ever did it,
> but Solaris did for a long time, as did (IIRC) NetBSD/OpenBSD.

Ah, I didn't know about mips doing that. I also just remembered that
s390 supports running 31 bit kernels on all 64 bit machines, but there is
no longer official support for that from IBM's side AFAIK.

I certainly expect ARM to be similar to powperpc and sparc here,
and anyone trying to submit a 32 bit kernel port for a 64 bit platform
will have a hard time arguing why that should be accepted into mainline.

Arnd

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 00/36] AArch64 Linux kernel port

[Arnd Bergmann]

On Tuesday 17 July 2012, Jon Masters wrote:
> On 07/16/2012 08:16 AM, Pavel Machek wrote:
> 
> >> If an implementation supports AArch32 at EL3 there could be some
> >> physical (or some FPGA config) switch to choose between the two. But
> >> since AArch64 is mandated, I don't see why one would force AArch32 at
> >> EL3 and therefore all lower exception levels (and make a big part of the
> >> processor unused).
> > 
> > Actually I see one ... and I can bet it will happen.
> > 
> > So you create that shiny new ARMv8 compliant CPU, 8 cores, 2GHz. HTC
> > will want to use it with 1GB of RAM... and put around exiting OMAP
> > perihepals.
> 
> But that's why we have Eagle (A15). It's a very capable 32-bit design
> from ARM and far more sensible for such designs. You can easily build
> something with a few A15 clusters in it, as we're already seeing.

Right, I would say that with any CPU core more powerful than this one
or with more than a few of these, you will also have trouble coming
up with workloads that really require the CPU performance but don't
also require a 64 bit virtual address space in either user space
or kernel.

Arnd

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 00/36] AArch64 Linux kernel port

[Catalin Marinas]

On Mon, Jul 16, 2012 at 09:24:26AM +0100, Avi Kivity wrote:
> On 07/15/2012 03:16 PM, Catalin Marinas wrote:
> > 
> > The AArch32 execution mode is optional, so it depends on the actual CPU
> > implementation (while AArch64 is mandatory). If the implementation
> > supports it, the most likely scenario for AArch32 at kernel level is in
> > virtual machines or the secure OS. I'll explain below why.
> > 
> > The exception (or privilege) levels on an ARMv8 architecture look like
> > this:
> > 
> > Secure WorldNormal World
> > +-+
> > | EL3 | - Secure monitor
> > +-+
> > +-+
> > | EL2 | - Hypervisor (normal world only)
> > +-+
> > +-+ +-+
> > | EL1 | | EL1 | - OS kernel (secure or normal)
> > +-+ +-+
> > +-+ +-+
> > | EL0 | | EL0 | - User apps (secure or normal)
> > +-+ +-+
> 
> Can the same kernel image run in both EL1 and EL2?  I noticed some .if
> ELs in the assembler files.  I guess they could be compiled multiple
> times and the correct version chosen at runtime, or patched up like x86
> does with alternative().
> 
> One of the advantages kvm has to Linux distributors is that the same
> kernel image can be used the hypervisor, guest, and bare metal.  I'd
> like to preserve that for arm64.

On ARM (the same on 32-bit) we can also run the same kernel image as
hypervisor or guest. Linux detects whether it was started in EL2 and
installs some layer for KVM to use later if needed and then drops to
EL1. If started in EL1, it doesn't have access to the virtualisation
features and it just runs as a guest.

The kernel cannot run in EL2 permanently as it cannot access user space
(EL2 has its own MMU tables, though compatible with the other levels).

-- 
Catalin
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 00/36] AArch64 Linux kernel port

[Jon Masters]

On 07/16/2012 04:24 AM, Avi Kivity wrote:

> Can the same kernel image run in both EL1 and EL2?  I noticed some .if
> ELs in the assembler files.  I guess they could be compiled multiple
> times and the correct version chosen at runtime, or patched up like x86
> does with alternative().

> One of the advantages kvm has to Linux distributors is that the same
> kernel image can be used the hypervisor, guest, and bare metal.  I'd
> like to preserve that for arm64.

The idea is that you would always enter at EL2 and then drop privilege
down to EL1 if you're not doing virt. That achieves effectively the same
thing that you get on x86. The virtualization in AArch64 is designed
more from the POV of separate hypervisors like Xen so we just need to
make sure we always start with enough privilege.

Jon.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 00/36] AArch64 Linux kernel port

[Jon Masters]

On 07/16/2012 08:16 AM, Pavel Machek wrote:

>> If an implementation supports AArch32 at EL3 there could be some
>> physical (or some FPGA config) switch to choose between the two. But
>> since AArch64 is mandated, I don't see why one would force AArch32 at
>> EL3 and therefore all lower exception levels (and make a big part of the
>> processor unused).
> 
> Actually I see one ... and I can bet it will happen.
> 
> So you create that shiny new ARMv8 compliant CPU, 8 cores, 2GHz. HTC
> will want to use it with 1GB of RAM... and put around exiting OMAP
> perihepals.

But that's why we have Eagle (A15). It's a very capable 32-bit design
from ARM and far more sensible for such designs. You can easily build
something with a few A15 clusters in it, as we're already seeing.

Jon.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 00/36] AArch64 Linux kernel port

[Christoph Hellwig]

On Sun, Jul 15, 2012 at 07:43:07PM +, Arnd Bergmann wrote:
> Yes, I agree that's the best way to handle this. Compared to other
> architectures, I think x86 is the only that allows booting either a
> 32 or 64 bit kernel on the same system. We used to support 32 bit
> kernels on 64 bit PowerMac, but nobody used it and we discontinued
> it long ago. Tile 64 bit is actually incompatible with 32 bit kernels
> at the architecture level and would require a third mode. On sparc,
> parisc and mips, AFAIK we could support 32 bit kernels on 64 bit
> machines, but never did.

On mips it works just fine.  On Sparc I don't think Linux ever did it,
but Solaris did for a long time, as did (IIRC) NetBSD/OpenBSD.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 00/36] AArch64 Linux kernel port

[Måns Rullgård]

Pavel Machek  writes:

> Hi!
>
>> The assembly syntax is very reasonable already and not far from what we
>> are used to (see the .S files in my kernel patches). The 64-bit
>> instructions are different and that's specified here (apart from the
>> actual bit encoding):
>> 
>> http://infocenter.arm.com/help/topic/com.arm.doc.genc010197a/index.html
>
> "This document is only available in a PDF version to registered ARM
> customers."
>
> It would be nice to make this public :-(.

Anyone can register, so it's not all that bad.

-- 
Måns Rullgård
m...@mansr.com
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 00/36] AArch64 Linux kernel port

[Arnd Bergmann]

On Monday 16 July 2012, Pavel Machek wrote:
> > The assembly syntax is very reasonable already and not far from what we
> > are used to (see the .S files in my kernel patches). The 64-bit
> > instructions are different and that's specified here (apart from the
> > actual bit encoding):
> > 
> > http://infocenter.arm.com/help/topic/com.arm.doc.genc010197a/index.html
> 
> "This document is only available in a PDF version to registered ARM
> customers."
> 
> It would be nice to make this public :-(.

Well, at least you can register for free and don't have to prove that you
are an ARM customer (who isn't, after all).

Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 00/36] AArch64 Linux kernel port

[Pavel Machek]

Hi!

> The assembly syntax is very reasonable already and not far from what we
> are used to (see the .S files in my kernel patches). The 64-bit
> instructions are different and that's specified here (apart from the
> actual bit encoding):
> 
> http://infocenter.arm.com/help/topic/com.arm.doc.genc010197a/index.html

"This document is only available in a PDF version to registered ARM
customers."

It would be nice to make this public :-(.
Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 00/36] AArch64 Linux kernel port

[Pavel Machek]

Hi!

> > > The AArch32 execution mode is optional, so it depends on the actual CPU
> > > implementation (while AArch64 is mandatory). If the implementation
> > > supports it, the most likely scenario for AArch32 at kernel level is in
> > > virtual machines or the secure OS. I'll explain below why.
> > > 
> > > The exception (or privilege) levels on an ARMv8 architecture look like
> > > this:
> > > 
> > > Secure WorldNormal World
> > > +-+
> > > | EL3 | - Secure monitor
> > > +-+
> > > +-+
> > > | EL2 | - Hypervisor (normal world only)
> > > +-+
> > > +-+ +-+
> > > | EL1 | | EL1 | - OS kernel (secure or normal)
> > > +-+ +-+
> > > +-+ +-+
> > > | EL0 | | EL0 | - User apps (secure or normal)
> > > +-+ +-+
> > > 
> > > In theory, each of these levels (implementation specific) can run both
> > > AArch32 and AArch64 modes. There is however a restriction on how the
> > > mode switching is done - this can only happen on a change of exception
> > > level. When going up the EL the register width (RW) can never go down. A
> > > lower EL can never have a higher RW than a higher EL.
> > > 
> > > Additionally, the RW (the AArch32/AArch64 mode) for an EL is controlled
> > > by the next higher level (with EL3 hard-wired). An EL cannot cause
> > > itself to switch between AArch32 and AArch64.
> > 
> > So is the highest level always hardwired to 64-bit on ARMv8?
> 
> If an implementation supports AArch32 at EL3 there could be some
> physical (or some FPGA config) switch to choose between the two. But
> since AArch64 is mandated, I don't see why one would force AArch32 at
> EL3 and therefore all lower exception levels (and make a big part of the
> processor unused).

Actually I see one ... and I can bet it will happen.

So you create that shiny new ARMv8 compliant CPU, 8 cores, 2GHz. HTC
will want to use it with 1GB of RAM... and put around exiting OMAP
perihepals.

At that point they will have choice of either:

1) going arm64, with no advantages and disadvantage of having to
debug/stabilize arm64 kernel+toolchain (+hardware; yes, early 64bit
hardware usually has security bugs), and to port the omap code from
arch/arm to arch/arm64

2) just putting that 8 cores into arm32 mode. Yes, a bit of silicion
is unused. But if the ARMv8 has most cores/biggest performance, it
still makes sense, and 32bits is inherently faster due to pointers
being smaller.

I know I did boot early amd64 machines in 32bit mode; avoiding all the
64bit complexity. I'm pretty sure someone will want to do that on arm.

Now, you may say "we'll just refuse to merge 32-bit support for 64-bit
capable machines"... I believe that's unneccessarily cruel... and may
rule out multi-user servers due to security problems.

  Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 00/36] AArch64 Linux kernel port

[Geert Uytterhoeven]

On Sun, Jul 15, 2012 at 9:43 PM, Arnd Bergmann  wrote:
> Yes, I agree that's the best way to handle this. Compared to other
> architectures, I think x86 is the only that allows booting either a
> 32 or 64 bit kernel on the same system. We used to support 32 bit
> kernels on 64 bit PowerMac, but nobody used it and we discontinued
> it long ago. Tile 64 bit is actually incompatible with 32 bit kernels
> at the architecture level and would require a third mode. On sparc,
> parisc and mips, AFAIK we could support 32 bit kernels on 64 bit
> machines, but never did.

Linux on MIPS supports both 32-bit and 64-bit kernels on 64-bit capable CPUs.

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 00/36] AArch64 Linux kernel port

[Avi Kivity]

On 07/15/2012 03:16 PM, Catalin Marinas wrote:
> 
> The AArch32 execution mode is optional, so it depends on the actual CPU
> implementation (while AArch64 is mandatory). If the implementation
> supports it, the most likely scenario for AArch32 at kernel level is in
> virtual machines or the secure OS. I'll explain below why.
> 
> The exception (or privilege) levels on an ARMv8 architecture look like
> this:
> 
> Secure World  Normal World
> +-+
> | EL3 |   - Secure monitor
> +-+
>   +-+
>   | EL2 | - Hypervisor (normal world only)
>   +-+
> +-+   +-+
> | EL1 |   | EL1 | - OS kernel (secure or normal)
> +-+   +-+
> +-+   +-+
> | EL0 |   | EL0 | - User apps (secure or normal)
> +-+   +-+

Can the same kernel image run in both EL1 and EL2?  I noticed some .if
ELs in the assembler files.  I guess they could be compiled multiple
times and the correct version chosen at runtime, or patched up like x86
does with alternative().

One of the advantages kvm has to Linux distributors is that the same
kernel image can be used the hypervisor, guest, and bare metal.  I'd
like to preserve that for arm64.

-- 
error compiling committee.c: too many arguments to function


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 00/36] AArch64 Linux kernel port

[Linus Torvalds]

On Sun, Jul 15, 2012 at 4:21 PM, Måns Rullgård  wrote:
>
> FWIW, I'd prefer naming the directory either arm64 or armv8 for a few
> reasons:
>
> - Those are the names people actually use to refer to the architecture
> - They are more descriptive.
> - I think the official name is rather silly.

Agreed on those three for arm64.

However, please don't use the *INSANE* ARM "v8" naming. There must be
something in the water in Cambridge, but the ARM "version" naming is
just totally broken. They have separate versions for their
"architecture" (ex: arm v8) and for their "implementation" (ex:
ARM11), and maybe it all makes sense if you have drunk the ARM
cool-aid and have joined the ARM cult, but to sane people and
outsiders, it is just a f*cking mess.

So

 - aarch64 is just another druggie name that the ARM people came up
with after drinking too much of the spiked water in cambridge.

   It is apparently ARM deciding to emulate every single bad idea that
Intel ever cam up with, and is the ARM version of the "ia64" name
(which is Intel's equally confusing name for "Intel architecture 64",
which a few years ago meant Itanium, but now in more modern times when
Intel tries to forget Itanium ever existed it means x86-64).

   "ia64" was a horrible name, aarch64 is the exact same mistake. It sucks.

 - armv8 is totally idiotic and incomprehensible to anybody else,
since quite frankly, the difference between "ARMv8" (the architecture
spec) and "ARM7" (the processor family) is complete and utter
nonsense. It's only confusing.

Christ. Seriously. The insanity is so strong in the ARM version names
that it burns. If it really makes sense to anybody that "ARM A9"
(technically "Cortex-A9", but nobody seems to use the "Cortex" part at
least in cellphones) is an "ARM-v7" architecture microprocessor which
is *completely* different from the ARM9 family, which in turn is
different from ARMv9 that hasn't happened yet, you need to have your
head examined.

So please don't use "aarch64", because it's just f*cking crazy. And
please don't use "armv8", because it's just completely retarded and
confused.

I don't think *anybody* would be confused by "arm-64" (or "arm64").

Of course, some day ARM Ltd will (unless they install new water
filtration plants) have "v64" of their architecture spec or introduce
the "ARM64 processor family". But that day is a long time from now,
and hopefully we could head that off at the pass by just calling the
64-bit arm "arm64" and some sane people inside ARM.

  Linus
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 00/36] AArch64 Linux kernel port

[Måns Rullgård]

Catalin Marinas  writes:

> On Tue, Jul 10, 2012 at 08:10:23AM +0100, Ingo Molnar wrote:
>> * Arnd Bergmann  wrote:
>> > On Saturday 07 July 2012, Olof Johansson wrote:
>> > > > ARM introduced AArch64 as part of the ARMv8 architecture
>> > > 
>> > > With the risk of bikeshedding here, but I find the name awkward. How
>> > > about just naming the arch port arm64 instead? It's considerably more
>> > > descriptive in the context of the kernel.  For reference, we didn't
>> > > name ppc64, nor powerpc, after what the IBM/power.org marketing people
>> > > were currently calling the architecture at the time either.
>> > 
>> > I agree the name sucks, [...]
>> 
>> So why not change it now, when it only bothers a few dozen 
>> people and it is only present in 36 patches? Why go full steam 
>> ahead to annoy thousands of people with it and why spread the 
>> naming madness to thousands of commits?
>
> Changing the arch/ dir name is easy at this point. My preference is for
> consistency with the official name (that cannot be changed) and the gcc
> triplet. I also don't think it annoys thousands of people, most don't
> really care. The few reactions I've seen is pretty much because people
> were expecting arm64 and it came as something else.

FWIW, I'd prefer naming the directory either arm64 or armv8 for a few
reasons:

- Those are the names people actually use to refer to the architecture
- They are more descriptive.
- I think the official name is rather silly.

Note, these are my personal opinions.

-- 
Måns Rullgård
m...@mansr.com
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 00/36] AArch64 Linux kernel port

[Catalin Marinas]

On Sun, Jul 15, 2012 at 08:43:07PM +0100, Arnd Bergmann wrote:
> On Sunday 15 July 2012, Catalin Marinas wrote:
> > The AArch32 execution mode is optional, so it depends on the actual CPU
> > implementation (while AArch64 is mandatory). If the implementation
> > supports it, the most likely scenario for AArch32 at kernel level is in
> > virtual machines or the secure OS. I'll explain below why.
> > 
> > The exception (or privilege) levels on an ARMv8 architecture look like
> > this:
> > 
> > Secure WorldNormal World
> > +-+
> > | EL3 | - Secure monitor
> > +-+
> > +-+
> > | EL2 | - Hypervisor (normal world only)
> > +-+
> > +-+ +-+
> > | EL1 | | EL1 | - OS kernel (secure or normal)
> > +-+ +-+
> > +-+ +-+
> > | EL0 | | EL0 | - User apps (secure or normal)
> > +-+ +-+
> > 
> > In theory, each of these levels (implementation specific) can run both
> > AArch32 and AArch64 modes. There is however a restriction on how the
> > mode switching is done - this can only happen on a change of exception
> > level. When going up the EL the register width (RW) can never go down. A
> > lower EL can never have a higher RW than a higher EL.
> > 
> > Additionally, the RW (the AArch32/AArch64 mode) for an EL is controlled
> > by the next higher level (with EL3 hard-wired). An EL cannot cause
> > itself to switch between AArch32 and AArch64.
> 
> So is the highest level always hardwired to 64-bit on ARMv8?

If an implementation supports AArch32 at EL3 there could be some
physical (or some FPGA config) switch to choose between the two. But
since AArch64 is mandated, I don't see why one would force AArch32 at
EL3 and therefore all lower exception levels (and make a big part of the
processor unused).

It's also impossible for some software to detect whether it runs in
AArch32 or AArch64. The instruction encodings are different, so any
instructions would have to be targeted at one mode or the other,
otherwise they are undefined.

> On a related note: how does the endianess change between
> exception levels on ARMv8? Can you switch endianess every time you
> move from one level to another? Can any of the levels pick the
> endianess for itself?

Yes, a level higher than 0 can pick the endianness for itself using the
SCTLR_ELx.EE bit. For user apps, the endianness is set by the kernel.
The SETEND instruction to switch the endianness on the fly (usually in
user space) is not available in AArch64 and has also been deprecated in
AArch32 on ARMv8. It wasn't too popular.

-- 
Catalin
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 00/36] AArch64 Linux kernel port

[Arnd Bergmann]

On Sunday 15 July 2012, Catalin Marinas wrote:
> The AArch32 execution mode is optional, so it depends on the actual CPU
> implementation (while AArch64 is mandatory). If the implementation
> supports it, the most likely scenario for AArch32 at kernel level is in
> virtual machines or the secure OS. I'll explain below why.
> 
> The exception (or privilege) levels on an ARMv8 architecture look like
> this:
> 
> Secure WorldNormal World
> +-+
> | EL3 | - Secure monitor
> +-+
> +-+
> | EL2 | - Hypervisor (normal world only)
> +-+
> +-+ +-+
> | EL1 | | EL1 | - OS kernel (secure or normal)
> +-+ +-+
> +-+ +-+
> | EL0 | | EL0 | - User apps (secure or normal)
> +-+ +-+
> 
> In theory, each of these levels (implementation specific) can run both
> AArch32 and AArch64 modes. There is however a restriction on how the
> mode switching is done - this can only happen on a change of exception
> level. When going up the EL the register width (RW) can never go down. A
> lower EL can never have a higher RW than a higher EL.
> 
> Additionally, the RW (the AArch32/AArch64 mode) for an EL is controlled
> by the next higher level (with EL3 hard-wired). An EL cannot cause
> itself to switch between AArch32 and AArch64.

So is the highest level always hardwired to 64-bit on ARMv8?

On a related note: how does the endianess change between
exception levels on ARMv8? Can you switch endianess every time you
move from one level to another? Can any of the levels pick the
endianess for itself?

> So while it is possible, the primary target for 32-bit at the OS kernel
> level is virtualisation. We also don't plan to support a 32-bit SoC on
> ARMv8 systems, given that the compat layer is fully functional.

Yes, I agree that's the best way to handle this. Compared to other
architectures, I think x86 is the only that allows booting either a
32 or 64 bit kernel on the same system. We used to support 32 bit
kernels on 64 bit PowerMac, but nobody used it and we discontinued
it long ago. Tile 64 bit is actually incompatible with 32 bit kernels
at the architecture level and would require a third mode. On sparc,
parisc and mips, AFAIK we could support 32 bit kernels on 64 bit
machines, but never did.

Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 00/36] AArch64 Linux kernel port

[Catalin Marinas]

On Sat, Jul 14, 2012 at 10:30:32AM +0100, Pavel Machek wrote:
> > > > Agreed. It's clear from the code that it started out as a copy 
> > > > of the 32 bit ARM code base, which I think was a mistake, but 
> > > > it has also moved on since then and many areas of the 64 bit 
> > > > code are now much cleaner because they don't have to worry 
> > > > about breaking legacy code. We're also more flexible with 
> > > > trying out stuff without having to worry about breaking some 
> > > > 10 year old board code.
> > > 
> > > Just for the record, you guys are repeating all the same 
> > > arguments that led to the x86_64 fork a decade ago...
> > 
> > As I stated already, comparing AArch64 to x86_64 is not right. So even
> > if the arguments may look the same, the context is *different*. AArch64
> > is *not* an extension to the AArch32 mode.
> 
> Is it possible to boot 32-bit OS on aarch64 machine?
> 
> IOW, is it compatible in supervisor mode, too?

The AArch32 execution mode is optional, so it depends on the actual CPU
implementation (while AArch64 is mandatory). If the implementation
supports it, the most likely scenario for AArch32 at kernel level is in
virtual machines or the secure OS. I'll explain below why.

The exception (or privilege) levels on an ARMv8 architecture look like
this:

Secure WorldNormal World
+-+
| EL3 | - Secure monitor
+-+
+-+
| EL2 | - Hypervisor (normal world only)
+-+
+-+ +-+
| EL1 | | EL1 | - OS kernel (secure or normal)
+-+ +-+
+-+ +-+
| EL0 | | EL0 | - User apps (secure or normal)
+-+ +-+

In theory, each of these levels (implementation specific) can run both
AArch32 and AArch64 modes. There is however a restriction on how the
mode switching is done - this can only happen on a change of exception
level. When going up the EL the register width (RW) can never go down. A
lower EL can never have a higher RW than a higher EL.

Additionally, the RW (the AArch32/AArch64 mode) for an EL is controlled
by the next higher level (with EL3 hard-wired). An EL cannot cause
itself to switch between AArch32 and AArch64.

AArch64 Linux always runs in normal world because that's where we have
virtualisation support for KVM etc. It is normally started at EL2 (but
falling shortly to EL1) unless it is a guest OS which does not have
access to the virtualisation features.

The secure world on the left hand side runs some dedicated secure
software and the communication between the two worlds is handled via
EL3. That's also the reset mode, so SoC firmware needs to run there. The
secure OS could be a 32-bit one given the investment security companies
put in certification (and that's one reason to have AArch32 support at
EL1)

On the Linux side, to be able to start a 32-bit ARM kernel the firmware
at EL3 would have to configure the lower modes as AArch32. Once that's
done, lower mode would never be able to upgrade itself to AArch64
(rendering all the AArch64 features pretty much unusable). So we require
that any SoC firmware starts the next stage boot-loader or non-secure OS
in AArch64. AArch64 Linux is able to change the execution mode for user
at EL0 (as it is lower). Guest OSes could also run in AArch32 long as
the host Linux has control of EL2.

So while it is possible, the primary target for 32-bit at the OS kernel
level is virtualisation. We also don't plan to support a 32-bit SoC on
ARMv8 systems, given that the compat layer is fully functional.

-- 
Catalin
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 00/36] AArch64 Linux kernel port

[Catalin Marinas]

On Sat, Jul 14, 2012 at 10:35:05AM +0100, Pavel Machek wrote:
> On Tue 2012-07-10 11:12:23, Catalin Marinas wrote:
> > On Sat, Jul 07, 2012 at 10:30:58AM +0100, Mikael Pettersson wrote:
> > > Catalin Marinas writes:
> > >  > Compilation requires a new aarch64-none-linux-gnu-
> > >  > toolchain (http://gcc.gnu.org/ml/gcc-patches/2012-05/msg01694.html).
> > > 
> > > Where are the corresponding binutils patches?  Without those it's
> > > impossible for people outside ARM to build the toolchain and kernel.
> > 
> > That's coming soon ;)
> 
> Actually, there's very little arm64 assembly written just now, what
> about using some reasonble syntax for the assembler?

The assembly syntax is very reasonable already and not far from what we
are used to (see the .S files in my kernel patches). The 64-bit
instructions are different and that's specified here (apart from the
actual bit encoding):

http://infocenter.arm.com/help/topic/com.arm.doc.genc010197a/index.html

> hexagon has something quite reasonable. Of course, one can not write
> such assembly without knowing the details, but at least one can read
> it... and maybe review.

Same here, one can read and review them. I doubt reviewers care about
the bit encoding ;).

-- 
Catalin
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 00/36] AArch64 Linux kernel port

[Jon Masters]

On 07/10/2012 04:16 PM, Alexander Holler wrote:

> And it isn't so that the name will have to be used that seldom, at least 
> every distribution would need to use it to name the flavour, like e.g. 
> "Fedora AArch64hf" or "Debian AArch64".

The good news is we won't need an "hf" release because we're all going
to just agree on the ABI on day one, and standardize the paths, and all
the distros are going to live happily ever after[0].

Jon.

[0] The first part at least is actually true. There is an ABI that I
reviewed a long time back (you can download it), and we assume the
presence of all kinds of previously optional stuff...like the fp.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 00/36] AArch64 Linux kernel port

[Pavel Machek]

On Tue 2012-07-10 11:12:23, Catalin Marinas wrote:
> On Sat, Jul 07, 2012 at 10:30:58AM +0100, Mikael Pettersson wrote:
> > Catalin Marinas writes:
> >  > Compilation requires a new aarch64-none-linux-gnu-
> >  > toolchain (http://gcc.gnu.org/ml/gcc-patches/2012-05/msg01694.html).
> > 
> > Where are the corresponding binutils patches?  Without those it's
> > impossible for people outside ARM to build the toolchain and kernel.
> 
> That's coming soon ;)

Actually, there's very little arm64 assembly written just now, what
about using some reasonble syntax for the assembler?

hexagon has something quite reasonable. Of course, one can not write
such assembly without knowing the details, but at least one can read
it... and maybe review.

Hmm?
Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 00/36] AArch64 Linux kernel port

[Pavel Machek]

Hi!

> > > > With the risk of bikeshedding here, but I find the name awkward. How
> > > > about just naming the arch port arm64 instead? It's considerably more
> > > > descriptive in the context of the kernel.  For reference, we didn't
> > > > name ppc64, nor powerpc, after what the IBM/power.org marketing people
> > > > were currently calling the architecture at the time either.
> > > 
> > > I agree the name sucks, [...]
> > 
> > So why not change it now, when it only bothers a few dozen 
> > people and it is only present in 36 patches? Why go full steam 
> > ahead to annoy thousands of people with it and why spread the 
> > naming madness to thousands of commits?
> 
> Changing the arch/ dir name is easy at this point. My preference is for
> consistency with the official name (that cannot be changed) and the gcc
> triplet. I also don't think it annoys thousands of people, most don't
> really care. The few reactions I've seen is pretty much because people
> were expecting arm64 and it came as something else.

I guess I'm 3/1000 now... Anyway, gcc triplet can be changed, and
official name does not seem to matter.

> > > Agreed. It's clear from the code that it started out as a copy 
> > > of the 32 bit ARM code base, which I think was a mistake, but 
> > > it has also moved on since then and many areas of the 64 bit 
> > > code are now much cleaner because they don't have to worry 
> > > about breaking legacy code. We're also more flexible with 
> > > trying out stuff without having to worry about breaking some 
> > > 10 year old board code.
> > 
> > Just for the record, you guys are repeating all the same 
> > arguments that led to the x86_64 fork a decade ago...
> 
> As I stated already, comparing AArch64 to x86_64 is not right. So even
> if the arguments may look the same, the context is *different*. AArch64
> is *not* an extension to the AArch32 mode.

Is it possible to boot 32-bit OS on aarch64 machine?

IOW, is it compatible in supervisor mode, too?
Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 00/36] AArch64 Linux kernel port

[Rusty Russell]

On Wed, 11 Jul 2012 11:53:35 +0100, Catalin Marinas  
wrote:
> Hi Rusty,

Hi Catalin,

This is fun!

> On Wed, Jul 11, 2012 at 06:26:49AM +0100, Rusty Russell wrote:
> > I know it's a crazy idea, but why don't we try some actual analysis?
> 
> This kind of analysis is not relevant. It's not like you can use a tool
> to just mix the lines from one file with another and get a merged port.

Whether a tool or human would do it, using some methodology to measure
similarity of two ports seems more informative than relying on the gut
feel of developers.

> The tool claims unicore32 shares 57% with arch/arm. It gets confused in
> the same way because unicore32 started with the ARM port as the code
> base. Do we want it merged with arch/arm based on hashmatch?

It doesn't "get confused"; it means exactly what it says.  Sure, it's
rough, but it's unbiased.

And it indicates that arch/aarch64 is as related to arch/arm as
arch/unicore32 is, ie. no more than expected from an arm-derived port.
(I actually get 56% for unicore32, 52% for aarch64).

Thus I consider my previous position proven incorrect: aarch64 should be
its own tree.

> This tool also shows that pretty much most of the atomic.h file in
> AArch64 is the same with AArch32. That's completely wrong as the
> assembly syntax is different for the two architectures (even the asm
> comment has changed from @ to //). That's a file that can never be
> shared.

That's why I subtracted a randomly-chosen other arch (sparc) to try to
eliminate such boilerplate similarities.

Cheers,
Rusty.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 00/36] AArch64 Linux kernel port

[Alan Cox]

> What if they add 64-bit ARM support to arch/x86? AFAIK some of the
> machines are going to be basically PCs, including legacy I/O, ACPI
> and UEFI, so they are much closer to that than they are to anything
> in arch/arm. The instruction set of course is different, but you
> already said that this doesn't matter.

ACPI5 doesn't require legacy I/O although I guess as before people will
be reusing x86 components and might do so for hardware reasons.

Alan
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 00/36] AArch64 Linux kernel port

[Catalin Marinas]

Hi Rusty,

On Wed, Jul 11, 2012 at 06:26:49AM +0100, Rusty Russell wrote:
> On Tue, 10 Jul 2012 16:52:18 +, Arnd Bergmann  wrote:
> > On Tuesday 10 July 2012, Alan Cox wrote:
> > > > In the AArch32 kernel port many implementation decisions newer
> > > > architectures were made in a way that preserves backwards compatibility
> > > > to over 15 years ago (and for good reasons, ARMv4 hardware is still in
> > > > use). But keeping the same decisions in AArch64 is wrong.
> > > 
> > > Same argument as x86-32 v x86-64. Same issues about compatibility.
> > 
> > Similar but not the same. In case of x86-64 the hardware was actually
> > meant to run old 32 bit kernel binaries and still can. I don't
> 
> I know it's a crazy idea, but why don't we try some actual analysis?

This kind of analysis is not relevant. It's not like you can use a tool
to just mix the lines from one file with another and get a merged port.
It's useful if you want to prove plagiarism but I already admitted
openly that AArch64 is derived from the ARM port :).

Just to give an example on this hashmatch tool (with the 3.5-rc5
kernel):

$ ./blockhash -p '*.[chS]' arch/arm/ > arm.hash

$ find arch/unicore32/ -name '*.[chS]' -exec cat {} \; | wc -l
16384
$ /work/cmarinas/hashmatch/hashmatch -p '*.[chS]' arm.hash arch/unicore32/ | 
grep -e "|" | wc -l
9302

The tool claims unicore32 shares 57% with arch/arm. It gets confused in
the same way because unicore32 started with the ARM port as the code
base. Do we want it merged with arch/arm based on hashmatch?

According to this tool, AArch64 also shared 23% with x86, relatively
large given that it started from the arch/arm port (which in turn
started from arch/i386 long time ago).

I can go on and compare architectures with each-other but I really think
it's a waste of time.

> In 2.5.5, when arch/x86_64 was introduced it was 35412 lines of code.
> hashmatch (http://www.samba.org/~tridge/hashmatch) says that about 24642
> are identical with arch/i386 in the same kernel.  That's 70%.  Some of
> that's boilerplate: 9610 lines are in common with arch/sparc64 (27%),
> so let's say that 43% of x86-64 was specifically sharable with i386.
> 
> arch/aarch64/ is 22016 line of code.  Hashmatch says 12509 (57%) is in
> common with arch/arm.  But only 3232 lines (15%) are in common with
> sparc.  So let's say that 42% of aarch64 is specifically sharable with
> arm.

This tool also shows that pretty much most of the atomic.h file in
AArch64 is the same with AArch32. That's completely wrong as the
assembly syntax is different for the two architectures (even the asm
comment has changed from @ to //). That's a file that can never be
shared.

So ignoring the misleading tool, I did an analysis of the code
similarities with AArch32 a couple of months ago. It's about 5% files
that are close and could shared relatively easily but a significant part
of those are simple (header) files without algorithmic value and with
the copyright note being sometimes being longer than the code. There is
another 5-7% code that looks similar but merging them with AArch32
require more #ifdef's around the code (have a look at
arch/{arm,aarch64}/mm/mmu.c as an example).

The above is just on the current small AArch64 code base. I already said
a few times, there is still significant development to be done.

-- 
Catalin
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 00/36] AArch64 Linux kernel port

[Catalin Marinas]

On Tue, Jul 10, 2012 at 10:44:29PM +0100, Catalin Marinas wrote:
> On Tue, Jul 10, 2012 at 09:35:27PM +0100, Ingo Molnar wrote:
> > Do you *really* think that all of the 32-bit ARM code should 
> > essentially be thrown away when going to 64-bit ARM, that 
> > patches can only touch arch/arm64/ + drivers/ or the highway?
> 
> Definitely not, I don't think anyone claimed this. The 32-bit ARM code
> will have the same important place for a very long time, ARM Ltd isn't
> withdrawing support for this (it's the main revenue generator). I expect
> to see many new 32-bit platforms to appear, MP systems, big.little
> configurations etc. If there is need for bigger physical address space,
> LPAE support (even with its drawbacks) is still the preferred choice for
> mobile systems.

Just to be clear in case it doesn't look aligned with Arnd's comment.
I'm referring to the 32-bit ARM port - it has the same important place
as before, nothing from the 32-bit architecture code is thrown away
(over time, we may want to clean up old architecture versions but that's
a normal thing).

How the 32-bit ARM SoC is refactored and maintained it's up to the
arm-soc team and they are doing a great job.

-- 
Catalin
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 00/36] AArch64 Linux kernel port

[Ingo Molnar]

* Arnd Bergmann  wrote:

> > Do you really think that all of the 32-bit ARM code should 
> > essentially be thrown away when going to 64-bit ARM, that 
> > patches can only touch arch/arm64/ + drivers/ or the 
> > highway?
> 
> Yes.

Straight answer ;-)

> If you're curious, please have a look at 
> arch/arm/mach-spear13xx/. this is the latest platform that we 
> have added. [...]

Very nice.

> [...] It's fully functional (except PCI, which I hope will be 
> added in drivers/pci/bus, which is another story), A 
> significant portion of that platform deals with SMP support, 
> which is being standardized for AArch64, so there will be only 
> one implementation. Another big portion is DMA-engine support, 
> which is moving out of arch/arm as soon as we have a proper DT 
> binding. Finally there are some boilerplate header files that 
> are going away too.
> 
> Once we're done with this, we will basically need zero code in 
> arch/*/ to support a new platform, and that is very easy to 
> share between two distinct arch/* directories ;-)

Ok, arch specific platform code going away completely is a valid 
solution - if you can pull that off for all new hardware then 
arch/arm64/ might actually work.

The life time of ARM hw is also a lot shorter than on x86. Plus, 
given that Apple and MS keeps Linux away from their hardware 
cryptographically we only have to deal with hw makers who 
specifically *want* Linux support. A lot of the maintenance pain 
on x86 comes from the fact that Linux support on a lot of PC 
hardware is incidental, from the hw maker's POV.

Ok, sounds like a valid plan. Just fix the name please :-)

Thanks,

Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 00/36] AArch64 Linux kernel port

[Rusty Russell]

On Tue, 10 Jul 2012 16:52:18 +, Arnd Bergmann  wrote:
> On Tuesday 10 July 2012, Alan Cox wrote:
> > > In the AArch32 kernel port many implementation decisions newer
> > > architectures were made in a way that preserves backwards compatibility
> > > to over 15 years ago (and for good reasons, ARMv4 hardware is still in
> > > use). But keeping the same decisions in AArch64 is wrong.
> > 
> > Same argument as x86-32 v x86-64. Same issues about compatibility.
> 
> Similar but not the same. In case of x86-64 the hardware was actually
> meant to run old 32 bit kernel binaries and still can. I don't

I know it's a crazy idea, but why don't we try some actual analysis?

In 2.5.5, when arch/x86_64 was introduced it was 35412 lines of code.
hashmatch (http://www.samba.org/~tridge/hashmatch) says that about 24642
are identical with arch/i386 in the same kernel.  That's 70%.  Some of
that's boilerplate: 9610 lines are in common with arch/sparc64 (27%),
so let's say that 43% of x86-64 was specifically sharable with i386.

arch/aarch64/ is 22016 line of code.  Hashmatch says 12509 (57%) is in
common with arch/arm.  But only 3232 lines (15%) are in common with
sparc.  So let's say that 42% of aarch64 is specifically sharable with
arm.

Looks equivalent to me.  They will merge eventually.

That said:
1) It's nice to have a clear division of maintainer responsibilities in
   the near term.

2) PowerPC only "merged" by removing a raft of older platforms, and I
   don't think ARM is ready for that.

And yes, aarch64 is a stupid name.

Cheers,
Rusty.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 00/36] AArch64 Linux kernel port

[Chris Adams]

Once upon a time, Catalin Marinas   said:
>Changing the arch/ dir name is easy at this point. My preference is for
>consistency with the official name (that cannot be changed) and the gcc
>triplet.

What ARM Ltd. says is the "official" name isn't necessarily what the
rest of the world will call it.  Linux uses "i386" for what Intel calls
"IA-32" (which virtually nobody else uses).
-- 
Chris Adams 
Systems and Network Administrator - HiWAAY Internet Services
I don't speak for anybody but myself - that's enough trouble.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 00/36] AArch64 Linux kernel port

[Catalin Marinas]

On Tue, Jul 10, 2012 at 10:19:38PM +0100, Arnd Bergmann wrote:
> On Tuesday 10 July 2012, Ingo Molnar wrote:
> > Do you really think that all of the 32-bit ARM code should 
> > essentially be thrown away when going to 64-bit ARM, that 
> > patches can only touch arch/arm64/ + drivers/ or the highway?
> 
> Yes.
> 
> If you're curious, please have a look at arch/arm/mach-spear13xx/.
> this is the latest platform that we have added. It's fully
> functional (except PCI, which I hope will be added in
> drivers/pci/bus, which is another story), A significant portion
> of that platform deals with SMP support, which is being standardized
> for AArch64, so there will be only one implementation. Another
> big portion is DMA-engine support, which is moving out of arch/arm
> as soon as we have a proper DT binding. Finally there are some
> boilerplate header files that are going away too.
> 
> Once we're done with this, we will basically need zero code
> in arch/*/ to support a new platform, and that is very easy
> to share between two distinct arch/* directories ;-)

OK, so Arnd's plan for 32-bit ARM SoCs are even better than what I've
envisaged ;)

-- 
Catalin
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 00/36] AArch64 Linux kernel port

[Catalin Marinas]

(just replying to a couple of points now, I'll follow up tomorrow)

On Tue, Jul 10, 2012 at 09:35:27PM +0100, Ingo Molnar wrote:
> Do you *really* think that all of the 32-bit ARM code should 
> essentially be thrown away when going to 64-bit ARM, that 
> patches can only touch arch/arm64/ + drivers/ or the highway?

Definitely not, I don't think anyone claimed this. The 32-bit ARM code
will have the same important place for a very long time, ARM Ltd isn't
withdrawing support for this (it's the main revenue generator). I expect
to see many new 32-bit platforms to appear, MP systems, big.little
configurations etc. If there is need for bigger physical address space,
LPAE support (even with its drawbacks) is still the preferred choice for
mobile systems.

But this doesn't have much to do with the aarch64 port. 32-bit SoC code
goes under arch/arm/ and drivers/, there is no change here. 64-bit SoC
goes under drivers/ and, if absolutely necessary, under arch/aarch64 (or
arm64).

> The moment someone adds 64-bit CPU support to arch/arm/ and it's 
> merged we'll have an interesting situation on hand: support for 
> the same CPU in two different architectures in the kernel tree.

Unless I misunderstand you, adding 64-bit support to arch/arm/ means
pretty much doing a significant architecture port or somehow merging the
patches that I posted. I doubt this would go unnoticed (would be obvious
only looking at the diffstat) and such pull request should be rejected
until we get to an agreement on using one or the other.

If you meant ARMv8 32-bit support, this should be rejected by the
arm-soc team as ARMv8 has a 64-bit mode already.

-- 
Catalin
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 00/36] AArch64 Linux kernel port

[Arnd Bergmann]

On Tuesday 10 July 2012, Ingo Molnar wrote:
> So are you really convinced that the colorful ARM SoC world is 
> not going to go 64-bit and will all unify behind a platform, and 
> that we can actually force this process by not accepting 
> non-generic patches? Is such a platform design being enforced by 
> ARM, like Intel does it on the x86 side?

We can almost build a kernel for all modern platforms on 32 bit,
and we know what pieces are missing. There is no technical reason
why we don't have a single kernel for all ARMv6 and ARMv7 platforms
already, it's just a shitload of work to get there starting out
with the existing platform code.

Of course we will have a lot of embedded 64 bit ARM SoCs, but
I'm convinced that we can deal with those. Rejecting crappy
code is easy as long as you can point to what they got wrong
specifically. There will also be out of tree platforms that
might not follow the same standards, but who cares about those?

> > * Unlike on 32 bit, the different platforms cannot be 
> > compile-time exclusive. A platform port that cannot be enabled 
> > without breaking another platform is not getting merged.
> > 
> > * I do not expect board-specific kernel patches, at least no 
> > more than we have them on x86 with the occasional hack to work 
> > around a broken machine.
> 
> If 64-bit hardware is made on existing SoC designs, which looks 
> rather likely, then we are not in a position to reject kernel 
> support for them.
> 
> Saying 'no' is very rarely a valid option for hardware ugliness. 
> We are encouraged to say 'no' for software details that is 
> actionable by the author of the patches, but hardware ugliness 
> is rarely actionable on that level and we are not holding our 
> users hostage in general just to make a point about ugliness.

We're doing it already for 32 bit. All new 32 bit platforms have
to follow the strictest rules for doing things the right way.
With 64 bit, we can raise the entry barrier even higher.

A much bigger problem than getting new contributions to be done
right is fixing the existing ones without regressing on hardware
support.

> > * The differences between SoCs will be confined to device 
> > drivers to a much larger degree than they are on 32 bit, 
> > partly because the SoC companies are trying to be fit into the 
> > single-kernel model, and partly because we have added the 
> > infrastructure to allow it.
> 
> There's 600 KLOC of code in arch/arm/, that's 3 times larger 
> than arch/x86/. Most of it is not in any fashion related to the 
> bitness of the CPU, it's platform IO code that is in principle 
> bitness agnostic.
> 
> I have a really hard time imagining that all 64-bit ARM hardware 
> will be supported from drivers/: IRQ controllers, timer drivers, 
> all the ugly SoC details.
> 
> Do you really think that all of the 32-bit ARM code should 
> essentially be thrown away when going to 64-bit ARM, that 
> patches can only touch arch/arm64/ + drivers/ or the highway?

Yes.

If you're curious, please have a look at arch/arm/mach-spear13xx/.
this is the latest platform that we have added. It's fully
functional (except PCI, which I hope will be added in
drivers/pci/bus, which is another story), A significant portion
of that platform deals with SMP support, which is being standardized
for AArch64, so there will be only one implementation. Another
big portion is DMA-engine support, which is moving out of arch/arm
as soon as we have a proper DT binding. Finally there are some
boilerplate header files that are going away too.

Once we're done with this, we will basically need zero code
in arch/*/ to support a new platform, and that is very easy
to share between two distinct arch/* directories ;-)

> The moment someone adds 64-bit CPU support to arch/arm/ and it's 
> merged we'll have an interesting situation on hand: support for 
> the same CPU in two different architectures in the kernel tree.

What if they add 64-bit ARM support to arch/x86? AFAIK some of the
machines are going to be basically PCs, including legacy I/O, ACPI
and UEFI, so they are much closer to that than they are to anything
in arch/arm. The instruction set of course is different, but you
already said that this doesn't matter.

Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 00/36] AArch64 Linux kernel port

[Ingo Molnar]

* Arnd Bergmann  wrote:

> > What plans to other maintainers and board vendors have ? Any 
> > design choice has to cope with these happening if a third 
> > party goes and does it.
> 
> It is slightly worrying to have multiple SoC vendors working 
> on their own platform support. There are a few things we can 
> assume though:
> 
> * Everyone who has an AArch64 implementation has access to 
> Catalin's kernel patches in is basing their stuff on top of 
> it.
> 
> * Most likely they are all working on server chips, which 
> means they want to have their hardware supported in upstream 
> kernels and enterprise distros.

Dunno, the moment Apple comes out with their 64-bit iPhone6 (or 
whichever version they'll go 64-bit) *everyone* will scramble to 
go 64-bit, for marketing reasons. Code and SoC details will be 
ported to 64-bit in the usual fashion: in the crudest, fastest 
possible way.

There's also a technological threshold: once RAM in a typical 
smartphone goes above 2GB the pain of a 32-bit kernel becomes 
significant. We are only about a year away from that point.

So are you *really* convinced that the colorful ARM SoC world is 
not going to go 64-bit and will all unify behind a platform, and 
that we can actually force this process by not accepting 
non-generic patches? Is such a platform design being enforced by 
ARM, like Intel does it on the x86 side?

> * Unlike on 32 bit, the different platforms cannot be 
> compile-time exclusive. A platform port that cannot be enabled 
> without breaking another platform is not getting merged.
> 
> * I do not expect board-specific kernel patches, at least no 
> more than we have them on x86 with the occasional hack to work 
> around a broken machine.

If 64-bit hardware is made on existing SoC designs, which looks 
rather likely, then we are not in a position to reject kernel 
support for them.

Saying 'no' is very rarely a valid option for hardware ugliness. 
We are encouraged to say 'no' for software details that is 
actionable by the author of the patches, but hardware ugliness 
is rarely actionable on that level and we are not holding our 
users hostage in general just to make a point about ugliness.

> * The differences between SoCs will be confined to device 
> drivers to a much larger degree than they are on 32 bit, 
> partly because the SoC companies are trying to be fit into the 
> single-kernel model, and partly because we have added the 
> infrastructure to allow it.

There's 600 KLOC of code in arch/arm/, that's 3 times larger 
than arch/x86/. Most of it is not in any fashion related to the 
bitness of the CPU, it's platform IO code that is in principle 
bitness agnostic.

I have a really hard time imagining that all 64-bit ARM hardware 
will be supported from drivers/: IRQ controllers, timer drivers, 
all the ugly SoC details.

Do you *really* think that all of the 32-bit ARM code should 
essentially be thrown away when going to 64-bit ARM, that 
patches can only touch arch/arm64/ + drivers/ or the highway?

The moment someone adds 64-bit CPU support to arch/arm/ and it's 
merged we'll have an interesting situation on hand: support for 
the same CPU in two different architectures in the kernel tree.

Anyway, I'm not an ARM person so I really don't want to make 
your life harder, I just wanted to potentially save you the 2 
years of extreme unification stress that the x86 tree went 
through ;-)

Thanks,

Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 00/36] AArch64 Linux kernel port

[Alexander Holler]

Am 10.07.2012 19:14, schrieb Joe Perches:

On Tue, 2012-07-10 at 11:10 +0100, Catalin Marinas wrote:

On Tue, Jul 10, 2012 at 08:10:23AM +0100, Ingo Molnar wrote:

* Arnd Bergmann  wrote:

On Saturday 07 July 2012, Olof Johansson wrote:

ARM introduced AArch64 as part of the ARMv8 architecture


With the risk of bikeshedding here, but I find the name awkward. How
about just naming the arch port arm64 instead? It's considerably more
descriptive in the context of the kernel.  For reference, we didn't
name ppc64, nor powerpc, after what the IBM/power.org marketing people
were currently calling the architecture at the time either.


I agree the name sucks, [...]


So why not change it now, when it only bothers a few dozen
people and it is only present in 36 patches? Why go full steam
ahead to annoy thousands of people with it and why spread the
naming madness to thousands of commits?


Changing the arch/ dir name is easy at this point. My preference is for
consistency with the official name (that cannot be changed) and the gcc
triplet. I also don't think it annoys thousands of people, most don't
really care. The few reactions I've seen is pretty much because people
were expecting arm64 and it came as something else.


Count me as one of the 1000s that think it's a poor name choice.
I think it's a poor name for marketing purposes too.


Add me to the thousands too.

Using AArch64 is like calling a fly Brachycera or a dog Canis lupus 
familiaris. It might be correct, but it is a name I wouldn't want to use 
when I would need to name the architecture. Try to make a presentation 
where you have to say AArch64 a dozen times. Those two As are imho just 
annoying to speak, besides that AArch64 doesn't given a hint by itself 
that is meant for ARM processors.


And it isn't so that the name will have to be used that seldom, at least 
every distribution would need to use it to name the flavour, like e.g. 
"Fedora AArch64hf" or "Debian AArch64".


Regards,

Alexander
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 00/36] AArch64 Linux kernel port

[richard -rw- weinberger]

On Tue, Jul 10, 2012 at 8:01 PM, Jan Ceuleers  wrote:
> Perhaps it's a typo, and was meant to be AArgh64 :-)

Still a much better name than aarch64.

-- 
Thanks,
//richard
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 00/36] AArch64 Linux kernel port

[Jan Ceuleers]

On 07/10/2012 07:14 PM, Joe Perches wrote:
> Count me as one of the 1000s that think it's a poor name choice.
> I think it's a poor name for marketing purposes too.
> 
> Best of luck with whatever is used.

Perhaps it's a typo, and was meant to be AArgh64 :-)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 00/36] AArch64 Linux kernel port

[Dennis Gilmore]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

El Tue, 10 Jul 2012 11:10:18 +0100
Catalin Marinas  escribió:
> On Tue, Jul 10, 2012 at 08:10:23AM +0100, Ingo Molnar wrote:
> > * Arnd Bergmann  wrote:
> > > On Saturday 07 July 2012, Olof Johansson wrote:
> > > > > ARM introduced AArch64 as part of the ARMv8 architecture
> > > > 
> > > > With the risk of bikeshedding here, but I find the name
> > > > awkward. How about just naming the arch port arm64 instead?
> > > > It's considerably more descriptive in the context of the
> > > > kernel.  For reference, we didn't name ppc64, nor powerpc,
> > > > after what the IBM/power.org marketing people were currently
> > > > calling the architecture at the time either.
> > > 
> > > I agree the name sucks, [...]
> > 
> > So why not change it now, when it only bothers a few dozen 
> > people and it is only present in 36 patches? Why go full steam 
> > ahead to annoy thousands of people with it and why spread the 
> > naming madness to thousands of commits?
> 
> Changing the arch/ dir name is easy at this point. My preference is
> for consistency with the official name (that cannot be changed) and
> the gcc triplet. I also don't think it annoys thousands of people,
> most don't really care. The few reactions I've seen is pretty much
> because people were expecting arm64 and it came as something else.
> 
> But I'll make a decision on this before the next version of the
> series.
> 
> > > [...] This also includes the rpm and dpkg architecture names, 
> > > and the string returned by the uname syscall. If everything 
> > > else is aarch64, we should use that in the kernel directory 
> > > too, but if everyone calls it arm64 anyway, we should probably 
> > > use that name for as many things as possible.
> > 
> > Yeah.
> 
> What are Red Hat's plans for the AArh64 rpm architecture name?

the rpm arch will be the output of uname -m

As i've said previously I personally prefer arm64 I think it will be
better for users but they will learn if it ends up being aarch64.


if uname -m is arm64 we will have foo-1.1-1.arm64.rpm 
if uname -m ends up as aarch64 we will have foo-1.1-1.aarch64.rpm

Dennis
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.18 (GNU/Linux)

iEYEARECAAYFAk/8XewACgkQkSxm47BaWfe/xwCgqq9ctMj9VG6zruJtmLDzrRZM
Ew8AoJRACBzQCLHLkoSveQ+2XoIrw1rY
=e8W0
-END PGP SIGNATURE-

Re: [PATCH 00/36] AArch64 Linux kernel port

[Joe Perches]

On Tue, 2012-07-10 at 11:10 +0100, Catalin Marinas wrote:
> On Tue, Jul 10, 2012 at 08:10:23AM +0100, Ingo Molnar wrote:
> > * Arnd Bergmann  wrote:
> > > On Saturday 07 July 2012, Olof Johansson wrote:
> > > > > ARM introduced AArch64 as part of the ARMv8 architecture
> > > > 
> > > > With the risk of bikeshedding here, but I find the name awkward. How
> > > > about just naming the arch port arm64 instead? It's considerably more
> > > > descriptive in the context of the kernel.  For reference, we didn't
> > > > name ppc64, nor powerpc, after what the IBM/power.org marketing people
> > > > were currently calling the architecture at the time either.
> > > 
> > > I agree the name sucks, [...]
> > 
> > So why not change it now, when it only bothers a few dozen 
> > people and it is only present in 36 patches? Why go full steam 
> > ahead to annoy thousands of people with it and why spread the 
> > naming madness to thousands of commits?
> 
> Changing the arch/ dir name is easy at this point. My preference is for
> consistency with the official name (that cannot be changed) and the gcc
> triplet. I also don't think it annoys thousands of people, most don't
> really care. The few reactions I've seen is pretty much because people
> were expecting arm64 and it came as something else.

Count me as one of the 1000s that think it's a poor name choice.
I think it's a poor name for marketing purposes too.

Best of luck with whatever is used.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 00/36] AArch64 Linux kernel port

[Catalin Marinas]

On Tue, Jul 10, 2012 at 04:33:58PM +0100, Alan Cox wrote:
> > In the AArch32 kernel port many implementation decisions newer
> > architectures were made in a way that preserves backwards compatibility
> > to over 15 years ago (and for *good* reasons, ARMv4 hardware is still in
> > use). But keeping the same decisions in AArch64 is wrong.
> 
> Same argument as x86-32 v x86-64. Same issues about compatibility.

I don't deny that the arguments may be the same (I should go back and
read those threads). The AArch64 context is different and we can't do a
comparison with the x86 case.

> > AArch64 is also in its early days with a lot of developments to come
> > (and still waiting for hardware). Until we really know the final shape,
> > the AArch64 code base must allowed to evolve independently from the
> > AArch32 one.
> 
> That is one area where while the merge was needed and a lot of work the
> original split may well have been sensible for x86-64 as well.

That's exactly why I don't see the point in arguing whether the current
AArch64 port should be merged into arch/arm/.

> > The initial target is servers (see the companies that have announced
> > plans around ARMv8) but I agree, we may see it in other devices in the
> > future. But as the maintainer I have no plans to support a 32-bit SoC on
> > an AArch64/ARMv8 system (which may or may not support AArch32 at kernel
> > level). If an AArch64 SoC would share some devices with an AArch32 SoC,
> > such code will go to drivers/.
> 
> What plans to other maintainers and board vendors have ? Any design choice
> has to cope with these happening if a third party goes and does it.

Very few vendors (or architecture licensees) went public on this, so
cannot speak for their plans. But there are ongoing private discussions
on standardising relevant parts of the SoC, having a common firmware API
for CPU booting, possibly using ACPI. Again, it's early development
stage.

If a third party tries to push a 32-bit ARMv8 SoC port, I rely on the
arm-soc team (Arnd, Olof) to reject it. It's similar to the argument
against people running a 32-bit kernel on x86_64 hardware. The main
reason we have 32-bit at the EL1 (kernel) level is for virtualisation
where one may want to run a 32-bit guest OS.

-- 
Catalin
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 00/36] AArch64 Linux kernel port

[Arnd Bergmann]

On Tuesday 10 July 2012, Alan Cox wrote:
> > In the AArch32 kernel port many implementation decisions newer
> > architectures were made in a way that preserves backwards compatibility
> > to over 15 years ago (and for good reasons, ARMv4 hardware is still in
> > use). But keeping the same decisions in AArch64 is wrong.
> 
> Same argument as x86-32 v x86-64. Same issues about compatibility.

Similar but not the same. In case of x86-64 the hardware was actually
meant to run old 32 bit kernel binaries and still can. I don't
expect to see any 64 bit ARM systems running 32 bit kernels, and
I will almost certainly reject any attempt to submit such a platform
support to the arm-soc tree.

Another difference is the amount of legacy code for 32 bit ARM, which
no other architecture comes close to. With AArch64 we really want to
do a lot of things in a more modern way, and doing in in a common tree
would mean having to change a lot of old code at once. We might get
there eventually, but I would not want to depend on it.

> > The initial target is servers (see the companies that have announced
> > plans around ARMv8) but I agree, we may see it in other devices in the
> > future. But as the maintainer I have no plans to support a 32-bit SoC on
> > an AArch64/ARMv8 system (which may or may not support AArch32 at kernel
> > level). If an AArch64 SoC would share some devices with an AArch32 SoC,
> > such code will go to drivers/.
> 
> What plans to other maintainers and board vendors have ? Any design choice
> has to cope with these happening if a third party goes and does it.

It is slightly worrying to have multiple SoC vendors working on their
own platform support. There are a few things we can assume though:

* Everyone who has an AArch64 implementation has access to Catalin's
kernel patches in is basing their stuff on top of it.

* Most likely they are all working on server chips, which means they
want to have their hardware supported in upstream kernels and
enterprise distros.

* Unlike on 32 bit, the different platforms cannot be compile-time
exclusive. A platform port that cannot be enabled without breaking
another platform is not getting merged.

* I do not expect board-specific kernel patches, at least no more
than we have them on x86 with the occasional hack to work around
a broken machine.

* The differences between SoCs will be confined to device drivers
to a much larger degree than they are on 32 bit, partly because
the SoC companies are trying to be fit into the single-kernel
model, and partly because we have added the infrastructure to
allow it.

Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 00/36] AArch64 Linux kernel port

[Alan Cox]

> In the AArch32 kernel port many implementation decisions newer
> architectures were made in a way that preserves backwards compatibility
> to over 15 years ago (and for *good* reasons, ARMv4 hardware is still in
> use). But keeping the same decisions in AArch64 is wrong.

Same argument as x86-32 v x86-64. Same issues about compatibility.

> AArch64 is also in its early days with a lot of developments to come
> (and still waiting for hardware). Until we really know the final shape,
> the AArch64 code base must allowed to evolve independently from the
> AArch32 one.

That is one area where while the merge was needed and a lot of work the
original split may well have been sensible for x86-64 as well.

> The initial target is servers (see the companies that have announced
> plans around ARMv8) but I agree, we may see it in other devices in the
> future. But as the maintainer I have no plans to support a 32-bit SoC on
> an AArch64/ARMv8 system (which may or may not support AArch32 at kernel
> level). If an AArch64 SoC would share some devices with an AArch32 SoC,
> such code will go to drivers/.

What plans to other maintainers and board vendors have ? Any design choice
has to cope with these happening if a third party goes and does it.

Alan


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 00/36] AArch64 Linux kernel port

[Catalin Marinas]

On Tue, Jul 10, 2012 at 08:10:23AM +0100, Ingo Molnar wrote:
> * Arnd Bergmann  wrote:
> > On Saturday 07 July 2012, Olof Johansson wrote:
> > > > ARM introduced AArch64 as part of the ARMv8 architecture
> > > 
> > > With the risk of bikeshedding here, but I find the name awkward. How
> > > about just naming the arch port arm64 instead? It's considerably more
> > > descriptive in the context of the kernel.  For reference, we didn't
> > > name ppc64, nor powerpc, after what the IBM/power.org marketing people
> > > were currently calling the architecture at the time either.
> > 
> > I agree the name sucks, [...]
> 
> So why not change it now, when it only bothers a few dozen 
> people and it is only present in 36 patches? Why go full steam 
> ahead to annoy thousands of people with it and why spread the 
> naming madness to thousands of commits?

Changing the arch/ dir name is easy at this point. My preference is for
consistency with the official name (that cannot be changed) and the gcc
triplet. I also don't think it annoys thousands of people, most don't
really care. The few reactions I've seen is pretty much because people
were expecting arm64 and it came as something else.

But I'll make a decision on this before the next version of the series.

> > [...] This also includes the rpm and dpkg architecture names, 
> > and the string returned by the uname syscall. If everything 
> > else is aarch64, we should use that in the kernel directory 
> > too, but if everyone calls it arm64 anyway, we should probably 
> > use that name for as many things as possible.
> 
> Yeah.

What are Red Hat's plans for the AArh64 rpm architecture name?

> > > I guess it's a good chance to clean up some of it and start 
> > > from a clean slate, if you can avoid the temptation of just 
> > > moving over code.
> > 
> > Agreed. It's clear from the code that it started out as a copy 
> > of the 32 bit ARM code base, which I think was a mistake, but 
> > it has also moved on since then and many areas of the 64 bit 
> > code are now much cleaner because they don't have to worry 
> > about breaking legacy code. We're also more flexible with 
> > trying out stuff without having to worry about breaking some 
> > 10 year old board code.
> 
> Just for the record, you guys are repeating all the same 
> arguments that led to the x86_64 fork a decade ago...

As I stated already, comparing AArch64 to x86_64 is not right. So even
if the arguments may look the same, the context is *different*. AArch64
is *not* an extension to the AArch32 mode.

In the AArch32 kernel port many implementation decisions newer
architectures were made in a way that preserves backwards compatibility
to over 15 years ago (and for *good* reasons, ARMv4 hardware is still in
use). But keeping the same decisions in AArch64 is wrong.

If you want to put the two architectures under the same directory, you
pretty much end up with duplicate files or subdirectories. If there is
little code shared, then I don't see the point. It's just creating more
work to maintain the build system, the include/asm/ (as AArch64 uses
lots more generic headers).

AArch64 is also in its early days with a lot of developments to come
(and still waiting for hardware). Until we really know the final shape,
the AArch64 code base must allowed to evolve independently from the
AArch32 one.

> With the difference that the case for unifying platforms seems 
> even *stronger* in the ARM space than it is in the x86 space: 
> 32-bit computing will probably stay around with us far longer in 
> the gadget and appliance space than in the server space. 
> Thinking that arm64 will only be limited to servers is rather 
> short-sighted, IMO.

The initial target is servers (see the companies that have announced
plans around ARMv8) but I agree, we may see it in other devices in the
future. But as the maintainer I have no plans to support a 32-bit SoC on
an AArch64/ARMv8 system (which may or may not support AArch32 at kernel
level). If an AArch64 SoC would share some devices with an AArch32 SoC,
such code will go to drivers/.

-- 
Catalin
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 00/36] AArch64 Linux kernel port

[Catalin Marinas]

On Sat, Jul 07, 2012 at 10:30:58AM +0100, Mikael Pettersson wrote:
> Catalin Marinas writes:
>  > Compilation requires a new aarch64-none-linux-gnu-
>  > toolchain (http://gcc.gnu.org/ml/gcc-patches/2012-05/msg01694.html).
> 
> Where are the corresponding binutils patches?  Without those it's
> impossible for people outside ARM to build the toolchain and kernel.

That's coming soon ;)

-- 
Catalin
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 00/36] AArch64 Linux kernel port

[Ingo Molnar]

* Arnd Bergmann  wrote:

> On Saturday 07 July 2012, Olof Johansson wrote:
> 
> > > ARM introduced AArch64 as part of the ARMv8 architecture
> > 
> > With the risk of bikeshedding here, but I find the name awkward. How
> > about just naming the arch port arm64 instead? It's considerably more
> > descriptive in the context of the kernel.  For reference, we didn't
> > name ppc64, nor powerpc, after what the IBM/power.org marketing people
> > were currently calling the architecture at the time either.
> 
> I agree the name sucks, [...]

So why not change it now, when it only bothers a few dozen 
people and it is only present in 36 patches? Why go full steam 
ahead to annoy thousands of people with it and why spread the 
naming madness to thousands of commits?

> [...] and I'd much prefer to just call it arm64 as well.

Then do it! :-)

arch/aarch64/ is a heck of a toungue twister, it's double typing 
all over the place and if everyone calls it arm64 anyway I'd 
suggest you change the code, not people!

> [...] The main advantage of the aarch64 name is that it's the 
> same as the identifier in the elf triplet, and it makes sense 
> to keep the same name for all places where we need to identify 
> the architecture. [...]

Doesn't really matter in practice: we have arch/x86/ which isnt 
the elf triplet either, and besides some minimal kbuild glue 
it's not an issue, and having a good short name matters quite a 
bit when trying to write good kernel code.

Wouldn't be the first time the GNU toolchain embarked on silly, 
user-hostile naming. i386-unknown-Linux, anyone?

So there's no valid technical reason there that I can see.

> [...] This also includes the rpm and dpkg architecture names, 
> and the string returned by the uname syscall. If everything 
> else is aarch64, we should use that in the kernel directory 
> too, but if everyone calls it arm64 anyway, we should probably 
> use that name for as many things as possible.

Yeah.

> > I guess it's a good chance to clean up some of it and start 
> > from a clean slate, if you can avoid the temptation of just 
> > moving over code.
> 
> Agreed. It's clear from the code that it started out as a copy 
> of the 32 bit ARM code base, which I think was a mistake, but 
> it has also moved on since then and many areas of the 64 bit 
> code are now much cleaner because they don't have to worry 
> about breaking legacy code. We're also more flexible with 
> trying out stuff without having to worry about breaking some 
> 10 year old board code.

Just for the record, you guys are repeating all the same 
arguments that led to the x86_64 fork a decade ago...

With the difference that the case for unifying platforms seems 
even *stronger* in the ARM space than it is in the x86 space: 
32-bit computing will probably stay around with us far longer in 
the gadget and appliance space than in the server space. 
Thinking that arm64 will only be limited to servers is rather 
short-sighted, IMO.

It all reminds me of what Sir John Templeton said: “The four 
most dangerous words in investing are, it’s different this 
time.”

Thanks,

Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 00/36] AArch64 Linux kernel port

[Arnd Bergmann]

On Monday 09 July 2012, Catalin Marinas wrote:
> On Mon, Jul 09, 2012 at 04:32:11PM +0100, Arnd Bergmann wrote:
> > We have a lot of reviewers that are familiar with the 32 bit code, so
> > I think the main strategy should be to spot duplicate code early
> > and make sure we deal with it individually. Examples for this are
> > probably the implementations for kvm and perf, which largely deal
> > with the same hardware on both architectures. Those definitely must
> > not get duplicated into mostly-identical files. In many cases, we're
> > moving those things into drivers/*, in other cases we might want to
> > use Makefile logic to include a sub-directory from one arch into another,
> > as we do for arch/um.
> 
> I don't see why we would need to get a subdir from one into the other.
> If the SoCs would need some common drivers (like GPIO), they should go
> into drivers/ anyway. There is some perf code that could be shared
> (though not building a subdir as we have different instruction sets) but
> I would like that moved to a more generic place.

I think either way works for the two examples I've given, we can do
whatever people are more comfortable with. All architectures today have
kvm and perf under arch/*/* so we could keep it that way and do an
ugly redirect, or we could get everyone to move to drivers/.

Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 00/36] AArch64 Linux kernel port

[Catalin Marinas]

Arnd,

On Mon, Jul 09, 2012 at 04:32:11PM +0100, Arnd Bergmann wrote:
> We have a lot of reviewers that are familiar with the 32 bit code, so
> I think the main strategy should be to spot duplicate code early
> and make sure we deal with it individually. Examples for this are
> probably the implementations for kvm and perf, which largely deal
> with the same hardware on both architectures. Those definitely must
> not get duplicated into mostly-identical files. In many cases, we're
> moving those things into drivers/*, in other cases we might want to
> use Makefile logic to include a sub-directory from one arch into another,
> as we do for arch/um.

I don't see why we would need to get a subdir from one into the other.
If the SoCs would need some common drivers (like GPIO), they should go
into drivers/ anyway. There is some perf code that could be shared
(though not building a subdir as we have different instruction sets) but
I would like that moved to a more generic place.

-- 
Catalin
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 00/36] AArch64 Linux kernel port

[Mark Brown]

On Mon, Jul 09, 2012 at 03:02:22PM +0100, Matthew Garrett wrote:
> On Mon, Jul 09, 2012 at 02:56:26PM +0100, Mark Brown wrote:

> > Where is this discussion?

> My part of it has pretty much been in-person discussion with Grant 
> Likely, but there was some on ksummit-discuss last month.

Oh, I saw some of the ksummit-discuss traffic but didn't register it as
a serious proposal to do something.

> > Right, but there's lots of bolierplate code with this stuff anyway and
> > it's not fundamentally hard.  Last time I looked at ACPI it had a rather
> > different model for how all this stuff would work than DT did which
> > isn't terribly helpful here.

> ACPI 5 lets devices expose their GPIO resources directly, so in some 
> cases a driver will just be able to request that and handle things as it 

Assuming the naming standard is the same and so on...  my understanding
was that it's difficult to get any sort of standardisation on ACPI
bindings for device drivers.

> would in ftd. But the more traditional ACPI method is to use ACPI 
> notifications, and those happen in process context. It seems unlikely 
> that everyone's going to get it right unless there's existing in-kernel 
> infrastructure for handling this.

Oh dear, that sounds awesome.


signature.asc
Description: Digital signature

Re: [PATCH 00/36] AArch64 Linux kernel port

[Alan Cox]

> I think the main strategy should be to spot duplicate code early
> and make sure we deal with it individually. Examples for this are
> probably the implementations for kvm and perf, which largely deal
> with the same hardware on both architectures. Those definitely must
> not get duplicated into mostly-identical files. In many cases, we're
> moving those things into drivers/*, in other cases we might want to
> use Makefile logic to include a sub-directory from one arch into another,
> as we do for arch/um.

If you want to put a subdir of one arch into another wouldn't it be
rather cleaner to use arm/arm/aarch64/ as your architecture base ?

Alan
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 00/36] AArch64 Linux kernel port

[Arnd Bergmann]

On Monday 09 July 2012, Alan Cox wrote:
> > > These are the same reasons the x86_64 people gave and regretted later.
> > 
> > I would not compare the x86_64 extension to the AArch64 architecture.
> 
> 
> It's not an architecture specific observation. I was just observing that
> you were following a pattern which in all other cases ended up with a
> merged tree.

All except ia64, which is probably considered a good thing nowadays,
even though there is still a significant amount of shared code between
ia64 and x86.

In case of sh64, my feeling is that the fact that it's now is more
a burden than a benefit, given that all relevant arch/sh systems
are the 32 bit variant.

Another interesting example is unicore32, which actually shares more
code with arch/arm than the proposed arch/aarch64 does. I think the
unicore32 code base would benefit from being merged back into arch/arm
as a third instruction set, but the additional maintainance cost for
everyone working on ARM makes that unrealistic.

> Now it could be your tree is different, it could be that the right
> approach in all these cases is actually to do a new tree and merge five
> years later - I don't know.

It's always a tradeoff. Right now I think it's better for both arm
and aarch64 to live as separate architectures, and it will remain that
way for a number of years. Some people suggested that we might want to
keep the two split initially but add support for the "modern" 32 bit
platforms in a mixed 32/64 arch/aarch directory like we did for
powerpc, but I'm rather skeptical about that. On powerpc, that resulted
in a cleaner end result than doing the merge first would have, but
it was also a long and painful process.
It's good to know that we have the option though, in case we decide
to merge in a few years after all.

> It's your (aarch64 folks) project at the end of the day and you who have
> to keep all the fixes and errata and whatnot in sync between the two
> trees and I don't personally care too much which way it happens.

We have a lot of reviewers that are familiar with the 32 bit code, so
I think the main strategy should be to spot duplicate code early
and make sure we deal with it individually. Examples for this are
probably the implementations for kvm and perf, which largely deal
with the same hardware on both architectures. Those definitely must
not get duplicated into mostly-identical files. In many cases, we're
moving those things into drivers/*, in other cases we might want to
use Makefile logic to include a sub-directory from one arch into another,
as we do for arch/um.

Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 00/36] AArch64 Linux kernel port

[Matthew Garrett]

On Mon, Jul 09, 2012 at 02:56:26PM +0100, Mark Brown wrote:
> On Mon, Jul 09, 2012 at 02:06:29PM +0100, Matthew Garrett wrote:
> 
> > There's ongoing discussion about unifying ACPI and ftd representation, 
> > and once that's done this isn't a problem, but right now there's no 
> 
> Where is this discussion?

My part of it has pretty much been in-person discussion with Grant 
Likely, but there was some on ksummit-discuss last month.

> > terribly straightforward way to do this without a lot of basically 
> > boilerplate code. The biggest issue is that ACPI has a very different 
> > idea about event delivery and we'd need some way to abstract that.
> 
> Right, but there's lots of bolierplate code with this stuff anyway and
> it's not fundamentally hard.  Last time I looked at ACPI it had a rather
> different model for how all this stuff would work than DT did which
> isn't terribly helpful here.

ACPI 5 lets devices expose their GPIO resources directly, so in some 
cases a driver will just be able to request that and handle things as it 
would in ftd. But the more traditional ACPI method is to use ACPI 
notifications, and those happen in process context. It seems unlikely 
that everyone's going to get it right unless there's existing in-kernel 
infrastructure for handling this.

-- 
Matthew Garrett | mj...@srcf.ucam.org
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 00/36] AArch64 Linux kernel port

[Mark Brown]

On Mon, Jul 09, 2012 at 02:06:29PM +0100, Matthew Garrett wrote:

> There's ongoing discussion about unifying ACPI and ftd representation, 
> and once that's done this isn't a problem, but right now there's no 

Where is this discussion?

> terribly straightforward way to do this without a lot of basically 
> boilerplate code. The biggest issue is that ACPI has a very different 
> idea about event delivery and we'd need some way to abstract that.

Right, but there's lots of bolierplate code with this stuff anyway and
it's not fundamentally hard.  Last time I looked at ACPI it had a rather
different model for how all this stuff would work than DT did which
isn't terribly helpful here.


signature.asc
Description: Digital signature

Re: [PATCH 00/36] AArch64 Linux kernel port

[Alan Cox]

> > These are the same reasons the x86_64 people gave and regretted later.
> 
> I would not compare the x86_64 extension to the AArch64 architecture.


It's not an architecture specific observation. I was just observing that
you were following a pattern which in all other cases ended up with a
merged tree.

Now it could be your tree is different, it could be that the right
approach in all these cases is actually to do a new tree and merge five
years later - I don't know.

It's your (aarch64 folks) project at the end of the day and you who have
to keep all the fixes and errata and whatnot in sync between the two
trees and I don't personally care too much which way it happens.

Alan
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 00/36] AArch64 Linux kernel port

[Geert Uytterhoeven]

On Mon, Jul 9, 2012 at 4:01 AM, Jon Masters  wrote:
> On 07/08/2012 06:24 PM, Dennis Gilmore wrote:
>> I know that the architecture really is new but thats not really clear
>> by adding AArch32 into the mix to represent 32 bit arm as ARM has done
>> or by calling it armv8. There is enough way to confuse them already why
>> confuse things more by adding yet another variable that is AArch64.
>> - From my and most of the other Fedora developers that i've discussed it
>> with its more like reluctant acceptance of AArch64 than thinking is a
>> good idea.
>
> btw, for clarification of anyone who is confused by the names...the new
> architecture is ARMv8. The 64-bit state is AArch64, during which the
> processor executes A64 instructions. The 32-bit state is AArch32, during
> which the processor executes either A32 ("ARM" version 7+) or T32
> ("Thumb" - I guess Thumb2+ really due to some of deprecation)
> instructions. I've noticed that there appears to be a clarification
> effort in which AArch64 is used as an architecture name when ARMv8 would
> be confusing, which is most of the time if you don't know whether you're
> referring to the new A64 instruction set or the older ones.

Ah, A64... sounds better than AArch64... Even AA64 sounds better than
AArch64

> Perhaps this is useful if someone is trying to figure out heads or tails
> of the different terms.

Many thanks! I was just googleing what this "T32" thingy was...

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 00/36] AArch64 Linux kernel port

[Matthew Garrett]

On Mon, Jul 09, 2012 at 01:32:56PM +0100, Mark Brown wrote:

> If you end up having to write two whole drivers that sounds enormously
> depressing especially for those of us working on devices that aren't
> architecture specific.  We've managed to avoid that thus far with device
> tree and platform data, would it not be possible to mandate that people
> use ACPI in a vaugley sane way which can support this too?

There's ongoing discussion about unifying ACPI and ftd representation, 
and once that's done this isn't a problem, but right now there's no 
terribly straightforward way to do this without a lot of basically 
boilerplate code. The biggest issue is that ACPI has a very different 
idea about event delivery and we'd need some way to abstract that.

-- 
Matthew Garrett | mj...@srcf.ucam.org
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 00/36] AArch64 Linux kernel port

[Mark Brown]

On Sat, Jul 07, 2012 at 04:29:08AM +0100, Matthew Garrett wrote:

> While mandating FDT is a massive advance over arm32, if there's a chance 
> that ACPI-based AArch64 platforms will ship in a similar timeframe to 
> FDT then I think we should ensure that ACPI and FDT are merged 
> beforehand - the alternative is that people are going to end up writing 
> the same hardware driver twice for different firmware implementations. I 
> don't think anyone benefits from introducing a platform that has 
> multiple device representations[1]

If you end up having to write two whole drivers that sounds enormously
depressing especially for those of us working on devices that aren't
architecture specific.  We've managed to avoid that thus far with device
tree and platform data, would it not be possible to mandate that people
use ACPI in a vaugley sane way which can support this too?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 00/36] AArch64 Linux kernel port

[Jan Engelhardt]

On Sunday 2012-07-08 12:18, Catalin Marinas wrote:
>
>On the good side, alphabetically it's before arch/alpha, so easier to
>grep.

And during `ls -l`, it'll happily scroll off the screen into oblivion :)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 00/36] AArch64 Linux kernel port

[Catalin Marinas]

Hi Alan,

On Sun, Jul 08, 2012 at 12:29:20AM +0100, Alan Cox wrote:
> > 1. The AArch64 architecture is significantly different from AArch32 (the
> > official name of the 32-bit ARM architecture), it is not an extension.
> > It has a new exception model, new instruction set (even the register
> > names are different), new C ABI, PCS. It has a hardware compat mode but
> > that's about it, there is no interworking between the two (not allowed
> > by hardware, nor that the ABIs would make this possible). 
> > 
> > 2. Easier code maintenance. While I started the kernel port from the
> > arch/arm/ code base (it was at a time when Linux didn't even have
> > generic unistd.h and the AArch64 specs kept changing) the code diverged
> > significantly both because of architecture differences and software
> > requirements like new ABI, generic headers (unistd.h, stat.h etc). The
> > port undergone significant rewrite following the rules for new
> > architecture ports and some of the few similarities will be moved to a
> > more generic place (like the mmu_gather patches from peterz). AArch64
> > SoCs are going into a more standardised direction and the SoC code will
> > be kept to a minimum and moved under drivers/. So merging AArch32 and
> > AArch64 together would be rather detrimental to code maintenance for
> > both architectures (#ifdef's or duplicate 32/64 files).
> > 
> > 3. Flexibility. It's early days for AArch64, we don't have a hardware
> > platform supported yet and there are ongoing debates around ACPI,
> > firmware standardisation for CPU booting, hotplug, power management. We
> > need the flexibility to improve the code base without worrying about
> > backwards compatibility (apart from the compat layer which isn't at all
> > affected by the hardware developments).
> 
> These are the same reasons the x86_64 people gave and regretted later.

I would not compare the x86_64 extension to the AArch64 architecture.
Unfortunately not all the specs are public yet and I can't point people
to the exception model which gives the full description of the AArch64
architecture.

Comparing with IA-64 is not entirely correct either but I would say the
AArch32/AArch64 diff is much closer to the x86/IA-64 diff than to the
x86_32/x86_64 one.

Just to give some highlights:

AArch32 (classic ARM) has r0-r14 32-bit general purpose registers (x14
is the stack pointer) and pc as the program counter. AArch64 has x0-x30
64-bit general purpose registers with the stack pointer (sp) as a
special one, similar to pc. To access the lower 32-bit part of general
registers on AArch64 we use w0-w30.

Following the register structure, the procedure calling standard (that's
a public document I mentioned in the cover) is also different. AArch32
uses r0-r3 as arguments with r4-r11 as the callee-saved registers. On
AArch64 we have x0-x7 as arguments, x8-x15 caller saved (a new addition
to AArch64), x19-x28 callee-saved. The rest are temporary or return
address (lr) registers.

The instruction set (called A64), while some mnemonics have been reused,
is a lot different. There are new instructions, there is no conditional
execution apart from the branch instruction (unlike A32 where pretty
much every instruction has a condition field encoded in the opcode).
Even the A64 instruction encodings are different from A32/T32. The best
thing about this is that they have been in a way that is optimal for
real apps without worrying about backwards compatibility.

The FPU (FP/SIMD) support is also re-designed with simplified exception
handling, new ISA.

In terms of exception model, AArch32 has USR mode for user apps and a
multitude of modes - SVC, IRQ, FIQ, ABT - for the kernel,  each with
their own banked lr (link register), sp and spsr (saved processor
state). AArch64 simplified this drastically with EL0 for user and just
EL1 for kernel with separate sp registers for each. All exceptions
handled by the kernel are taken in a single EL1 mode, no need to juggle
with switching between IRQ etc. and SVC like on AArch32. In addition,
there is a dedicated AArch64 ELR register for automatic saving of the
exception return address, unlike AArch32 where we had to temporarily
free r0 (by saving on the stack) just to be able to preserve the
information when switching between IRQ etc. and SVC.

As for the Linux implementation, the AArch32 and AArch64 ABIs are
entirely different - AArch64 uses generic syscalls (unistd.h), lots of
generic user structures, different ELF relocations (loadable modules).
The MMU is completely different from the classic ARM MMU (closer to
LPAE) and we have the advantage of not having to implement the MMU
support in a backwards compatible way, simplifying code like mm/mmu.c
greatly (and not only).

In conclusion, AArch64 hardware features together with the ongoing
effort on SoC and firmware standardisation allow for a much cleaner OS
implementation. I'm now looking forward to maintaining the AArch64
kernel port for the many years to come in the sam

Re: [PATCH 00/36] AArch64 Linux kernel port

[Catalin Marinas]

Hi Jon,

On 9 July 2012 03:01, Jon Masters  wrote:
> On 07/08/2012 06:24 PM, Dennis Gilmore wrote:
>> I know that the architecture really is new but thats not really clear
>> by adding AArch32 into the mix to represent 32 bit arm as ARM has done
>> or by calling it armv8. There is enough way to confuse them already why
>> confuse things more by adding yet another variable that is AArch64.
>> - From my and most of the other Fedora developers that i've discussed it
>> with its more like reluctant acceptance of AArch64 than thinking is a
>> good idea.
>
> btw, for clarification of anyone who is confused by the names...the new
> architecture is ARMv8. The 64-bit state is AArch64, during which the
> processor executes A64 instructions. The 32-bit state is AArch32, during
> which the processor executes either A32 ("ARM" version 7+) or T32
> ("Thumb" - I guess Thumb2+ really due to some of deprecation)
> instructions. I've noticed that there appears to be a clarification
> effort in which AArch64 is used as an architecture name when ARMv8 would
> be confusing, which is most of the time if you don't know whether you're
> referring to the new A64 instruction set or the older ones.

Thanks for clarifying this. I deliberately try not to use ARMv8 name
to avoid confusion. Indeed, the new architecture is ARMv8 (following
the ARM architectures numbering scheme). It has an AArch64 mode (with
new exception model, new ISA) and an *optional* AArch32 mode (pretty
much the same as ARMv7). The key here is that AArch32 is *optional* -
we can have it at all levels, only some (e.g. EL0 - user) or not at
all.

These two modes also share very little, from a software perspective
it's pretty much some register banking to allow compat mode support
(e.g. you can read the AArch32 R0 register from the lower half of
AArch64 X0). The AArch32 mode cannot switch by itself to an AArch64
mode, this requires taking an exception (can be SVC) to a higher level
that actually runs in AArch64 mode.

On an ARMv8 system, if it supports AArch32 at EL1 (kernel) you can run
an ARMv7 kernel, and that's good for virtualisation. But I have
*absolutely* no plans to support an AArch32 kernel for ARMv8 SoCs.

-- 
Catalin
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 00/36] AArch64 Linux kernel port

[Jon Masters]

On 07/08/2012 06:24 PM, Dennis Gilmore wrote:

> I know that the architecture really is new but thats not really clear
> by adding AArch32 into the mix to represent 32 bit arm as ARM has done
> or by calling it armv8. There is enough way to confuse them already why
> confuse things more by adding yet another variable that is AArch64.
> - From my and most of the other Fedora developers that i've discussed it
> with its more like reluctant acceptance of AArch64 than thinking is a
> good idea. 

btw, for clarification of anyone who is confused by the names...the new
architecture is ARMv8. The 64-bit state is AArch64, during which the
processor executes A64 instructions. The 32-bit state is AArch32, during
which the processor executes either A32 ("ARM" version 7+) or T32
("Thumb" - I guess Thumb2+ really due to some of deprecation)
instructions. I've noticed that there appears to be a clarification
effort in which AArch64 is used as an architecture name when ARMv8 would
be confusing, which is most of the time if you don't know whether you're
referring to the new A64 instruction set or the older ones.

Perhaps this is useful if someone is trying to figure out heads or tails
of the different terms.

Jon.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 00/36] AArch64 Linux kernel port

[Jon Masters]

On 07/08/2012 04:31 PM, Jan Engelhardt wrote:
> 
> On Sunday 2012-07-08 09:54, Jon Masters wrote:
>>
>> FWIW I actually really like the aarch64 name (but you know that already
>> :) ). I think it clearly spells out that this is not just a 64-bit
>> extension to the existing 32-bit ARM Architecture, it is a new (inspired
>> by ARM) architecture.
> 
> IA64 also has a "arch" inside, and look where it took them.
> (The contemporary platform winner came to be x86_64 instead
> of what Intel had hoped back then.)

There is a difference here. Treading carefully to avoid upsetting
anyone, but IA64 was a complete departure in many ways from x86, whereas
AMD had something that was backward compatible more directly, and the
market reacted. In this case, it's different because of many different
things - an ARMv8 processor will also be a great ARMv7 processor (albeit
a few things nobody ever used are deprecated, but still supported), the
makeup of the existing market (ARM doesn't need a 30 year backward
compatibility story on the desktop or server and mobile platforms have
moved on to higher level stacks), the dynamics of the licensing model,
and the fact that compiled code is less relevant. I would say let's not
draw too many comparisons with x86/IA64/x86_64.

AArch64 is not a complete departure for ARM. It's a 32-bit wide RISC
instruction set that is very clean and draws on industry lessons from
the past several decades to fix (AFAICS) pretty much anything that was
really wrong with A32/T32 (ARM). They already did a lot in ARMv7 in
terms of deprecating older features, but it's nice (from an
implementation point of view) to have a chance to remove things that no
longer make sense - like many conditional instructions, modelling real
world software to optimize the encoding formats, etc. - and clean up
stuff like explicit knowledge of the pipeline depth of ten years ago.

I am very keen on the opportunity here for things like a single zImage
and a standardized platform on day one. By the time the first hardware
ships, I'm hoping that we've got a nice set of standards that everyone
can follow - all things that are needed to do AArch64 in bigger systems.

Jon.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 00/36] AArch64 Linux kernel port

[Dennis Gilmore]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Sun, 08 Jul 2012 14:31:05 -0400
Jon Masters  wrote:

> On 07/08/2012 03:54 AM, Jon Masters wrote:
> 
> > In our bikeshedding conversations pondering future Fedora support,
> > we've pretty much settled on the aarch64 name now, and the hope is
> > that we can also avoid providing 32-bit compatibility (multi-arch)
> > by relying on virtualized guests for any 32-bit story. If that
> > holds, we have some flexibility to e.g. go for 64K page size, etc.
> > if we want.
> 
> Let me rephrase that to avoid missunderstanding. I am the strongest
> advocate of the "aarch64" name on our end. Others disagreed with that,
> but when the tooling, kernel, and other stuff settled on the same
> uniform name, it was my understanding that this was de facto settled.
> However, it would be wrong to say there are not dissenting viewpoints.
> 
> My biggest fear here, however, is that we end up bikeshedding this to
> death, and we then have some use of one name, some of "arm64", and
> distros failing to agree on things like the correct triplet to use for
> the new architecture (we had some issues with this before). So, if
> we're going to argue over the name and make changes, let's do it now.
> There seems to be no value in the toolchain using one name, which is
> already upstream, and the kernel using another name.
> 
> Jon.

I agree that we should be consistent between the tools and kernel.
triplets will always be different between distros.  I think that is a
given.  I personally don't like the name AArch64 I think that the Arch
is redundant and that the A is way to vague. is it Alpha? ARM? AMD?
armada-xp? Athlon? ? Yum today supports arm64 i do think that the distro
users at first will expect arm64 and go looking for the bits under
patches with arm64 in them. with education they will learn and it will
become second nature but that will take time. 

I know that the architecture really is new but thats not really clear
by adding AArch32 into the mix to represent 32 bit arm as ARM has done
or by calling it armv8. There is enough way to confuse them already why
confuse things more by adding yet another variable that is AArch64.
- From my and most of the other Fedora developers that i've discussed it
with its more like reluctant acceptance of AArch64 than thinking is a
good idea. 

Dennis
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.18 (GNU/Linux)

iEYEARECAAYFAk/6CJkACgkQkSxm47BaWfdT2QCdFf7lgiy2EoLhxIsPJ3L6N8UI
ILsAn2V+M2xX0vHhsAiL7hu5UL1vHn2Y
=OEuo
-END PGP SIGNATURE-
N‹§²æìr¸›yúèšØb²X¬¶Ç§vØ^–)Þº{.nÇ+‰·¥Š{±‘êçzX§¶›¡Ü¨}©ž²Æ zÚ&j:+v‰¨¾«‘êçzZ+€Ê+zf£¢·hšˆ§~†­†Ûiÿûàz¹®w¥¢¸?™¨è­Ú&¢)ߢf”ù^jÇ«y§m…á@A«a¶Úÿ
0¶ìh®å’i

Re: [PATCH 00/36] AArch64 Linux kernel port

[Jan Engelhardt]

On Sunday 2012-07-08 09:54, Jon Masters wrote:
>
>FWIW I actually really like the aarch64 name (but you know that already
>:) ). I think it clearly spells out that this is not just a 64-bit
>extension to the existing 32-bit ARM Architecture, it is a new (inspired
>by ARM) architecture.

IA64 also has a "arch" inside, and look where it took them.
(The contemporary platform winner came to be x86_64 instead
of what Intel had hoped back then.)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 00/36] AArch64 Linux kernel port

[Jan Engelhardt]

On Sunday 2012-07-08 07:05, Henrique de Moraes Holschuh wrote:
>>>
>>>I agree the name sucks, and I'd much prefer to just call it arm64 as
>>>well. The main advantage of the aarch64 name is that it's the same
>>>as the identifier in the elf triplet, [...] to identify the
>>>architecture, [...] the rpm and dpkg architecture names, and [...]
>>>the uname syscall.
>>
>>Any hindrance changing the specs? There is not even arm64 hardware - or
>>aarch64, for that matter - out there yet according to the initial post,
>>so I doubt there is anything in userspace yet.
>
>There is, in gnu config (the autoconf config.sub/config.guess stuff), and
>maybe some of the gnu toolchain?
>
>I did wonder why the awkward aarch64 identifier instead of something like
>arm64 which has also the benefit of good marketing by carrying the ARM name
>in the arch name, but since it was not my place to ask about it and ARM had
>already submitted "aarch64" to gnu upstream...

Well maybe ARM just wants to render itself unimportant. Fine by me, but 
the shareholders might think differently ;-)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 00/36] AArch64 Linux kernel port

[Jon Masters]

On 07/08/2012 03:54 AM, Jon Masters wrote:

> In our bikeshedding conversations pondering future Fedora support, we've
> pretty much settled on the aarch64 name now, and the hope is that we can
> also avoid providing 32-bit compatibility (multi-arch) by relying on
> virtualized guests for any 32-bit story. If that holds, we have some
> flexibility to e.g. go for 64K page size, etc. if we want.

Let me rephrase that to avoid missunderstanding. I am the strongest
advocate of the "aarch64" name on our end. Others disagreed with that,
but when the tooling, kernel, and other stuff settled on the same
uniform name, it was my understanding that this was de facto settled.
However, it would be wrong to say there are not dissenting viewpoints.

My biggest fear here, however, is that we end up bikeshedding this to
death, and we then have some use of one name, some of "arm64", and
distros failing to agree on things like the correct triplet to use for
the new architecture (we had some issues with this before). So, if we're
going to argue over the name and make changes, let's do it now. There
seems to be no value in the toolchain using one name, which is already
upstream, and the kernel using another name.

Jon.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 00/36] AArch64 Linux kernel port

[Jon Masters]

On 07/08/2012 07:17 AM, Dr. David Alan Gilbert wrote:
> * Jon Masters (j...@redhat.com) wrote:
>> On 07/07/2012 03:27 PM, Arnd Bergmann wrote:
>>> On Saturday 07 July 2012, Olof Johansson wrote:
>>>
> ARM introduced AArch64 as part of the ARMv8 architecture

 With the risk of bikeshedding here, but I find the name awkward. How
 about just naming the arch port arm64 instead? It's considerably more
 descriptive in the context of the kernel.  For reference, we didn't
 name ppc64, nor powerpc, after what the IBM/power.org marketing people
 were currently calling the architecture at the time either.
>>>
>>> I agree the name sucks, and I'd much prefer to just call it arm64
>>> as well. The main advantage of the aarch64 name is that it's the
>>> same as the identifier in the elf triplet, and it makes sense to
>>> keep the same name for all places where we need to identify the
>>> architecture. This also includes the rpm and dpkg architecture names,
>>> and the string returned by the uname syscall. If everything else
>>> is aarch64, we should use that in the kernel directory too, but
>>> if everyone calls it arm64 anyway, we should probably use that name
>>> for as many things as possible.
>>
>> FWIW I actually really like the aarch64 name (but you know that already
>> :) ). I think it clearly spells out that this is not just a 64-bit
>> extension to the existing 32-bit ARM Architecture, it is a new (inspired
>> by ARM) architecture. Implementations will also run in AArch32 state
>> (A32 and T32), but it's not like x86->x86_64.
> 
> It's one advantage is that it won't trigger the infinite number
> of broken scripts out there that do something on arm*

Indeed. I believe that was another reason for the name choice,
especially in the toolchain, but also in kernel/uname.

Jon.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 00/36] AArch64 Linux kernel port

[Dr. David Alan Gilbert]

* Jon Masters (j...@redhat.com) wrote:
> On 07/07/2012 03:27 PM, Arnd Bergmann wrote:
> > On Saturday 07 July 2012, Olof Johansson wrote:
> > 
> >>> ARM introduced AArch64 as part of the ARMv8 architecture
> >>
> >> With the risk of bikeshedding here, but I find the name awkward. How
> >> about just naming the arch port arm64 instead? It's considerably more
> >> descriptive in the context of the kernel.  For reference, we didn't
> >> name ppc64, nor powerpc, after what the IBM/power.org marketing people
> >> were currently calling the architecture at the time either.
> > 
> > I agree the name sucks, and I'd much prefer to just call it arm64
> > as well. The main advantage of the aarch64 name is that it's the
> > same as the identifier in the elf triplet, and it makes sense to
> > keep the same name for all places where we need to identify the
> > architecture. This also includes the rpm and dpkg architecture names,
> > and the string returned by the uname syscall. If everything else
> > is aarch64, we should use that in the kernel directory too, but
> > if everyone calls it arm64 anyway, we should probably use that name
> > for as many things as possible.
> 
> FWIW I actually really like the aarch64 name (but you know that already
> :) ). I think it clearly spells out that this is not just a 64-bit
> extension to the existing 32-bit ARM Architecture, it is a new (inspired
> by ARM) architecture. Implementations will also run in AArch32 state
> (A32 and T32), but it's not like x86->x86_64.

It's one advantage is that it won't trigger the infinite number
of broken scripts out there that do something on arm*

Dave
-- 
 -Open up your eyes, open up your mind, open up your code ---   
/ Dr. David Alan Gilbert|   Running GNU/Linux   | Happy  \ 
\ gro.gilbert @ treblig.org |   | In Hex /
 \ _|_ http://www.treblig.org   |___/
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 00/36] AArch64 Linux kernel port

[Catalin Marinas]

Hi Olof,

On Sat, Jul 07, 2012 at 04:53:08AM +0100, Olof Johansson wrote:
> On Fri, Jul 6, 2012 at 2:05 PM, Catalin Marinas
>  wrote:
> > ARM introduced AArch64 as part of the ARMv8 architecture
> 
> With the risk of bikeshedding here, but I find the name awkward. How
> about just naming the arch port arm64 instead? It's considerably more
> descriptive in the context of the kernel.  For reference, we didn't
> name ppc64, nor powerpc, after what the IBM/power.org marketing people
> were currently calling the architecture at the time either.

The name may not be as nice but AArch64 is the official architecture
name as per the (not yet released) ARM ARM. It's not a marketing name.
The complier triplet also uses it, so to avoid confusion I went with the
same. If you want a comparison, IA-64 is also coming form Intel but it
wasn't the architecture to be known as x86_64.

On the good side, alphabetically it's before arch/alpha :), so easier to
grep.

> > There is no hardware platform available at this point. From a kernel
> > perspective, the aim is to minimise (or even completely remove) the
> > platform code from the architecture specific directory. FDT is
> > currently mandated and there are ongoing discussions for ACPI
> > support.
> 
> This will be interesting to see how it plays out over time, and how
> many vendors will drop in arm64 cores on their existing designs and
> thus need to pull over infrastructure from arch/arm for their platform
> type. A lot of the drivers have moved out to common code so much of it
> should be possible to do cleanly, but there is still some risk for
> duplication.
> 
> I guess it's a good chance to clean up some of it and start from a
> clean slate, if you can avoid the temptation of just moving over code.

I agree, it's a great advantage to start with a clean port and I will
try as much as possible to keep the SoC code duplication to a minimum.
We'll also benefit from the experience of the arm-soc team, which I see
as taking active role in the AArch64 SoC support.

The architecture is also in a much better shape with generic timers, GIC
(though not the GICv2 version that we have on arch/arm/) so most of the
remaining SoC code would belong to drivers/. There is still debate
around CPU boot and power management and the firmware involvement and we
try to standardise this as well. Basically AArch64 Linux only runs in
non-secure mode but some operations require secure side code.

Thanks.

-- 
Catalin
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 00/36] AArch64 Linux kernel port

[Jon Masters]

On 07/07/2012 03:27 PM, Arnd Bergmann wrote:
> On Saturday 07 July 2012, Olof Johansson wrote:
> 
>>> ARM introduced AArch64 as part of the ARMv8 architecture
>>
>> With the risk of bikeshedding here, but I find the name awkward. How
>> about just naming the arch port arm64 instead? It's considerably more
>> descriptive in the context of the kernel.  For reference, we didn't
>> name ppc64, nor powerpc, after what the IBM/power.org marketing people
>> were currently calling the architecture at the time either.
> 
> I agree the name sucks, and I'd much prefer to just call it arm64
> as well. The main advantage of the aarch64 name is that it's the
> same as the identifier in the elf triplet, and it makes sense to
> keep the same name for all places where we need to identify the
> architecture. This also includes the rpm and dpkg architecture names,
> and the string returned by the uname syscall. If everything else
> is aarch64, we should use that in the kernel directory too, but
> if everyone calls it arm64 anyway, we should probably use that name
> for as many things as possible.

FWIW I actually really like the aarch64 name (but you know that already
:) ). I think it clearly spells out that this is not just a 64-bit
extension to the existing 32-bit ARM Architecture, it is a new (inspired
by ARM) architecture. Implementations will also run in AArch32 state
(A32 and T32), but it's not like x86->x86_64.

In our bikeshedding conversations pondering future Fedora support, we've
pretty much settled on the aarch64 name now, and the hope is that we can
also avoid providing 32-bit compatibility (multi-arch) by relying on
virtualized guests for any 32-bit story. If that holds, we have some
flexibility to e.g. go for 64K page size, etc. if we want.

Jon.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 00/36] AArch64 Linux kernel port

[Henrique de Moraes Holschuh]

On Sun, 08 Jul 2012, Jan Engelhardt wrote:
> On Saturday 2012-07-07 21:27, Arnd Bergmann wrote:
> >On Saturday 07 July 2012, Olof Johansson wrote:
> >> > ARM introduced AArch64 as part of the ARMv8 architecture
> >> 
> >> With the risk of bikeshedding here, but I find the name awkward. How
> >> about just naming the arch port arm64 instead?
> >
> >I agree the name sucks, and I'd much prefer to just call it arm64 as
> >well. The main advantage of the aarch64 name is that it's the same
> >as the identifier in the elf triplet, [...] to identify the
> >architecture, [...] the rpm and dpkg architecture names, and [...]
> >the uname syscall.
> 
> Any hindrance changing the specs? There is not even arm64 hardware - or
> aarch64, for that matter - out there yet according to the initial post,
> so I doubt there is anything in userspace yet.

There is, in gnu config (the autoconf config.sub/config.guess stuff), and
maybe some of the gnu toolchain?

I did wonder why the awkward aarch64 identifier instead of something like
arm64 which has also the benefit of good marketing by carrying the ARM name
in the arch name, but since it was not my place to ask about it and ARM had
already submitted "aarch64" to gnu upstream...

If ARM wants to change to a much better "arm64", I suggest ARM should move
*FAST* to get it changed in GNU config and the toolchain.  And tell the
downstream distro maintainers about it... yesterday.

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 00/36] AArch64 Linux kernel port

[Jan Engelhardt]

On Saturday 2012-07-07 21:27, Arnd Bergmann wrote:
>On Saturday 07 July 2012, Olof Johansson wrote:
>
>> > ARM introduced AArch64 as part of the ARMv8 architecture
>> 
>> With the risk of bikeshedding here, but I find the name awkward. How
>> about just naming the arch port arm64 instead?
>
>I agree the name sucks, and I'd much prefer to just call it arm64 as
>well. The main advantage of the aarch64 name is that it's the same
>as the identifier in the elf triplet, [...] to identify the
>architecture, [...] the rpm and dpkg architecture names, and [...]
>the uname syscall.

Any hindrance changing the specs? There is not even arm64 hardware - or
aarch64, for that matter - out there yet according to the initial post,
so I doubt there is anything in userspace yet.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 00/36] AArch64 Linux kernel port

[Jan Engelhardt]

On Saturday 2012-07-07 05:53, Olof Johansson wrote:
>
>> ARM introduced AArch64 as part of the ARMv8 architecture
>
>With the risk of bikeshedding here, but I find the name awkward. How
>about just naming the arch port arm64 instead? It's considerably more
>descriptive in the context of the kernel.  For reference, we didn't
>name ppc64, nor powerpc, after what the IBM/power.org marketing people
>were currently calling the architecture at the time either.

But then again, we went with the clumsy "x86_64" instead of the
well-credited "amd64". :)

(What was the name IBM used to call their hardware at that time?)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 00/36] AArch64 Linux kernel port

[Alan Cox]

> 1. The AArch64 architecture is significantly different from AArch32 (the
> official name of the 32-bit ARM architecture), it is not an extension.
> It has a new exception model, new instruction set (even the register
> names are different), new C ABI, PCS. It has a hardware compat mode but
> that's about it, there is no interworking between the two (not allowed
> by hardware, nor that the ABIs would make this possible). 
> 
> 2. Easier code maintenance. While I started the kernel port from the
> arch/arm/ code base (it was at a time when Linux didn't even have
> generic unistd.h and the AArch64 specs kept changing) the code diverged
> significantly both because of architecture differences and software
> requirements like new ABI, generic headers (unistd.h, stat.h etc). The
> port undergone significant rewrite following the rules for new
> architecture ports and some of the few similarities will be moved to a
> more generic place (like the mmu_gather patches from peterz). AArch64
> SoCs are going into a more standardised direction and the SoC code will
> be kept to a minimum and moved under drivers/. So merging AArch32 and
> AArch64 together would be rather detrimental to code maintenance for
> both architectures (#ifdef's or duplicate 32/64 files).
> 
> 3. Flexibility. It's early days for AArch64, we don't have a hardware
> platform supported yet and there are ongoing debates around ACPI,
> firmware standardisation for CPU booting, hotplug, power management. We
> need the flexibility to improve the code base without worrying about
> backwards compatibility (apart from the compat layer which isn't at all
> affected by the hardware developments).

These are the same reasons the x86_64 people gave and regretted later.

Alan
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 00/36] AArch64 Linux kernel port

[Catalin Marinas]

On Fri, Jul 06, 2012 at 11:58:04PM +0100, Alan Cox wrote:
> >  arch/x86/include/asm/atomic64_32.h  |1 +
> >  arch/x86/include/asm/atomic64_64.h  |1 +
> >  arch/xtensa/kernel/syscall.c|2 +-
> 
> This looks odd to say the least ?

There are a few preparatory patches at the beginning of this series that
will be merged separately but I wanted to give the full context of why
they are needed, hence posting them together with the AArch64 code.

> The only other question I'd ask is given that ppc and x86 have both done
> 32/64bit separate architectures and then gone the other way is that
> something ARM 64bit needs to think about ?

This has been debated and there are strong reasons to keep it separate:

1. The AArch64 architecture is significantly different from AArch32 (the
official name of the 32-bit ARM architecture), it is not an extension.
It has a new exception model, new instruction set (even the register
names are different), new C ABI, PCS. It has a hardware compat mode but
that's about it, there is no interworking between the two (not allowed
by hardware, nor that the ABIs would make this possible). 

2. Easier code maintenance. While I started the kernel port from the
arch/arm/ code base (it was at a time when Linux didn't even have
generic unistd.h and the AArch64 specs kept changing) the code diverged
significantly both because of architecture differences and software
requirements like new ABI, generic headers (unistd.h, stat.h etc). The
port undergone significant rewrite following the rules for new
architecture ports and some of the few similarities will be moved to a
more generic place (like the mmu_gather patches from peterz). AArch64
SoCs are going into a more standardised direction and the SoC code will
be kept to a minimum and moved under drivers/. So merging AArch32 and
AArch64 together would be rather detrimental to code maintenance for
both architectures (#ifdef's or duplicate 32/64 files).

3. Flexibility. It's early days for AArch64, we don't have a hardware
platform supported yet and there are ongoing debates around ACPI,
firmware standardisation for CPU booting, hotplug, power management. We
need the flexibility to improve the code base without worrying about
backwards compatibility (apart from the compat layer which isn't at all
affected by the hardware developments).

-- 
Catalin
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 00/36] AArch64 Linux kernel port

[Arnd Bergmann]

On Friday 06 July 2012, Alan Cox wrote:
> >  arch/x86/include/asm/atomic64_32.h  |1 +
> >  arch/x86/include/asm/atomic64_64.h  |1 +
> >  arch/xtensa/kernel/syscall.c|2 +-
> 
> This looks odd to say the least ?

See patch 1/36. I think it makes sense, though you could argue that
testing #ifdef atomic64_dec_if_positive would be nicer than testing
#ifdef ARCH_HAS_ATOMIC64_DEC_IF_POSITIVE.

> The only other question I'd ask is given that ppc and x86 have both done
> 32/64bit separate architectures and then gone the other way is that
> something ARM 64bit needs to think about ?

It's the most debated question so far, in the private review that we've
done before, and in the public Linaro meetings. You are right that everyone
else merged their architectures (and sparc, mips in addition ot the ones
you mentioned, parisc and tile were always combined IIRC).

I've also touched on this question in my reply to Olof, but I can give
a longer summary of what we talked about before and what I got out of it.
The basic argument is

a) Pro merge: Avoid code duplication, because duplicate code leads to duplicate
bugs and extra maintainance overhead.

b) Pro split: Start with a fresh code base without all the legacy code that
we are currently in the process of reworking; Most code is actually
different anyway.

I was long undecided in this and tried to look at both sides, but I'm now
leaning towards b).
Look at what's actually in the arch trees:

* Assembly code: On the other architectures, the 32 and 64 bit instruction
sets are mostly identical, normally with additional instructions for 64 bit,
but in case of ARM AArch64, the instruction set is actually completely new
and it's not possible to write assembler in a way that builds on both
versions.

* System call interface: Most architectures use the same user space ABI
for 32 and 64 bit, with minor variations. In case of AArch64, we use the
new generic ABI, while 32 bit ARM uses one that has grown over a long
time and carries around a lot of legacy baggage. AArch64 has to emulate
the 32 bit ABI for running old user space, but the 32-bit compat
implementation cannot actually share any code with the native 32 bit
one.

* Platform support: In most architectures, there is a single system-level
architecture describing stuff like interrupt controllers, timers, SMP
initialization, etc, and that is usually shared between 32 and 64 bit.
On 32 bit ARM, we have about 50 distinct platforms, but some of them
have a lot in common with platforms of another architecture (arm/shmobile
with sh, arm/imx with powerpc/85xx, arm/rpc with x86, ...). The same code
is what we're reworking currently and moving out of arch/arm into drivers
whereever that makes sense.

* Basic infrastructure: pci support, ptrace, signal handling, dma-mapping,
etc. A lot of things that are copied between architectures are actually
completely generic and should just be moved into common code out of the
arch/ directory structure. It's better to share these between aarch64 and
multiple other new architectures than just between 32 and 64 bit ARM.

Given all of these things that we are not going to share anyway, I think
it's better to be flexible with the new code and clean up or try out
things that we would not be able to change easily in a merged code base
without running the risk of introducing many regressions for 32 bit systems.
The risk of duplicating code is still there, but I think we can deal with
that on a case-by-case basis and make sure we don't merge duplicate
files that should either be shared in one form or another, or that should
be done differently to start with.

Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 00/36] AArch64 Linux kernel port

[Kirill A. Shutemov]

On Sat, Jul 07, 2012 at 11:30:58AM +0200, Mikael Pettersson wrote:
> Catalin Marinas writes:
>  > Compilation requires a new aarch64-none-linux-gnu-
>  > toolchain (http://gcc.gnu.org/ml/gcc-patches/2012-05/msg01694.html).
> 
> Where are the corresponding binutils patches?  Without those it's
> impossible for people outside ARM to build the toolchain and kernel.

I guess ARM doesn't want to expose instruction set details before the
time. ;)

-- 
 Kirill A. Shutemov
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 00/36] AArch64 Linux kernel port

[Arnd Bergmann]

On Saturday 07 July 2012, Olof Johansson wrote:

> > ARM introduced AArch64 as part of the ARMv8 architecture
> 
> With the risk of bikeshedding here, but I find the name awkward. How
> about just naming the arch port arm64 instead? It's considerably more
> descriptive in the context of the kernel.  For reference, we didn't
> name ppc64, nor powerpc, after what the IBM/power.org marketing people
> were currently calling the architecture at the time either.

I agree the name sucks, and I'd much prefer to just call it arm64
as well. The main advantage of the aarch64 name is that it's the
same as the identifier in the elf triplet, and it makes sense to
keep the same name for all places where we need to identify the
architecture. This also includes the rpm and dpkg architecture names,
and the string returned by the uname syscall. If everything else
is aarch64, we should use that in the kernel directory too, but
if everyone calls it arm64 anyway, we should probably use that name
for as many things as possible.

> > There is no hardware platform available at this point. From a kernel
> > perspective, the aim is to minimise (or even completely remove) the
> > platform code from the architecture specific directory. FDT is currently
> > mandated and there are ongoing discussions for ACPI support.
> 
> This will be interesting to see how it plays out over time, and how
> many vendors will drop in arm64 cores on their existing designs and
> thus need to pull over infrastructure from arch/arm for their platform
> type. A lot of the drivers have moved out to common code so much of it
> should be possible to do cleanly, but there is still some risk for
> duplication.

For new platforms, the risk is very low, even if they want to support
the same peripherals in both 32 and 64 bit kernels, since almost all
of that can be in drivers/ already. The main missing bits are the
lack of a place to put irqchip drivers (I think there are already
patches to create drivers/irqchip/) and dma engines require platform
specific setup code because of the lack of DT bindings (also being
worked on).

I'm a little more worried about platforms that have an existing 32 bit
code base and have developers that want to reuse the existing code.
We have to make it very clear from the start that copying platform
code from arch/arm to arch/arm64 is not acceptable. Using Makefile
magic to redirect into the 32 bit platform directory would be a
possibility but I would really hope we can get everyone to do a clean
64 platform from the start, and hopefully move the 32 bit code over
to use the same drivers over time, and drastically shrink their
exisiting platform code.

> I guess it's a good chance to clean up some of it and start from a
> clean slate, if you can avoid the temptation of just moving over code.

Agreed. It's clear from the code that it started out as a copy of the
32 bit ARM code base, which I think was a mistake, but it has also
moved on since then and many areas of the 64 bit code are now much
cleaner because they don't have to worry about breaking legacy code.
We're also more flexible with trying out stuff without having to
worry about breaking some 10 year old board code.

Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 00/36] AArch64 Linux kernel port

[Mikael Pettersson]

Catalin Marinas writes:
 > Compilation requires a new aarch64-none-linux-gnu-
 > toolchain (http://gcc.gnu.org/ml/gcc-patches/2012-05/msg01694.html).

Where are the corresponding binutils patches?  Without those it's
impossible for people outside ARM to build the toolchain and kernel.

/Mikael
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 00/36] AArch64 Linux kernel port

[Olof Johansson]

Catalin,

On Fri, Jul 6, 2012 at 2:05 PM, Catalin Marinas  wrote:
> This set of patches implements the core Linux support for the AArch64
> (64-bit ARM) architecture.

Hmm. I didn't see a cc to current ARM maintainer (Russell), nor did
you cc the topic list that you list in the MAINTAINERS entry. It's
probably considered appropriate to do both. Also,
linux-a...@vger.kernel.org usually has a cc of new architectures.

> ARM introduced AArch64 as part of the ARMv8 architecture

With the risk of bikeshedding here, but I find the name awkward. How
about just naming the arch port arm64 instead? It's considerably more
descriptive in the context of the kernel.  For reference, we didn't
name ppc64, nor powerpc, after what the IBM/power.org marketing people
were currently calling the architecture at the time either.

[...]

> There is no hardware platform available at this point. From a kernel
> perspective, the aim is to minimise (or even completely remove) the
> platform code from the architecture specific directory. FDT is currently
> mandated and there are ongoing discussions for ACPI support.

This will be interesting to see how it plays out over time, and how
many vendors will drop in arm64 cores on their existing designs and
thus need to pull over infrastructure from arch/arm for their platform
type. A lot of the drivers have moved out to common code so much of it
should be possible to do cleanly, but there is still some risk for
duplication.

I guess it's a good chance to clean up some of it and start from a
clean slate, if you can avoid the temptation of just moving over code.


-Olof
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 00/36] AArch64 Linux kernel port

[Matthew Garrett]

On Fri, Jul 06, 2012 at 10:05:41PM +0100, Catalin Marinas wrote:

> There is no hardware platform available at this point. From a kernel
> perspective, the aim is to minimise (or even completely remove) the
> platform code from the architecture specific directory. FDT is currently
> mandated and there are ongoing discussions for ACPI support.

While mandating FDT is a massive advance over arm32, if there's a chance 
that ACPI-based AArch64 platforms will ship in a similar timeframe to 
FDT then I think we should ensure that ACPI and FDT are merged 
beforehand - the alternative is that people are going to end up writing 
the same hardware driver twice for different firmware implementations. I 
don't think anyone benefits from introducing a platform that has 
multiple device representations[1]

[1] Yeah x86 has the same problem with PNP and ACPI and PCI and given 
how much pain that's caused me I wish someone had complained at the time

-- 
Matthew Garrett | mj...@srcf.ucam.org
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 00/36] AArch64 Linux kernel port

[Alan Cox]

>  arch/x86/include/asm/atomic64_32.h  |1 +
>  arch/x86/include/asm/atomic64_64.h  |1 +
>  arch/xtensa/kernel/syscall.c|2 +-

This looks odd to say the least ?

The only other question I'd ask is given that ppc and x86 have both done
32/64bit separate architectures and then gone the other way is that
something ARM 64bit needs to think about ?

Alan
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 00/36] AArch64 Linux kernel port

[Catalin Marinas]

This set of patches implements the core Linux support for the AArch64
(64-bit ARM) architecture.


ARM introduced AArch64 as part of the ARMv8 architecture and consists of
a substantially revised exception model (with 4 exception levels: EL0 -
user, EL1 - kernel, EL2 - hypervisor, EL3 - secure monitor), new A64
instruction set based on larger register file, new FP/SIMD instructions.
The new ABI is LP64 and takes advantage of the larger register file and
mandates FP.

AArch64 documentation currently available (publicly, though
click-through agreement required):

- Instruction Set Overview:
http://infocenter.arm.com/help/topic/com.arm.doc.genc010197a/index.html

- ABI (PCS, ELF, DWARF, C++):
http://infocenter.arm.com/help/topic/com.arm.doc.ihi0059a/index.html


The AArch64 Linux port follows the guidance for new architecture ports
using generic headers (including unistd.h) and as much generic code as
possible (some library functions may be later optimised, based on
benchmarking results).

There is no hardware platform available at this point. From a kernel
perspective, the aim is to minimise (or even completely remove) the
platform code from the architecture specific directory. FDT is currently
mandated and there are ongoing discussions for ACPI support.

In terms of MMU, it currently supports 39-bit address space for user and
kernel (each) with 3-level page table and 4KB pages or 2-level page
table and 64KB pages (see Documentation/aarch64/memory.txt). The virtual
address space can be extended to 48-bit.

Compat (32-bit) user applications (ARM EABI only) are supported with the
4KB page configuration. There is no interworking between AArch32 and
AArch64 code (the architecture requires an exception entry/exit to
change the mode).

Linux Test Project (LTP) and LAMP stack have been used to test and
validate this code against ARM simulation model throughout the
development. Compilation requires a new aarch64-none-linux-gnu-
toolchain (http://gcc.gnu.org/ml/gcc-patches/2012-05/msg01694.html).


These patches are also available on this branch:

git://git.kernel.org/pub/scm/linux/kernel/git/cmarinas/linux-aarch64.git 
upstream


Regards,

Catalin


Catalin Marinas (25):
  atomic64_test: Simplify the #ifdef for atomic64_dec_if_positive()
test
  fs: Build sys_stat64() and friends if __ARCH_WANT_COMPAT_STAT64
  fdt: Add generic dt_memblock_reserve() function
  AArch64: Assembly macros and definitions
  AArch64: Kernel booting and initialisation
  AArch64: Exception handling
  AArch64: MMU definitions
  AArch64: MMU initialisation
  AArch64: MMU fault handling and page table management
  AArch64: Process management
  AArch64: CPU support
  AArch64: Cache maintenance routines
  AArch64: TLB maintenance functionality
  AArch64: Atomic operations
  AArch64: Device specific operations
  AArch64: DMA mapping API
  AArch64: SMP support
  AArch64: ELF definitions
  AArch64: System calls handling
  AArch64: Signal handling support
  AArch64: User access library functions
  AArch64: Floating point and SIMD
  AArch64: Miscellaneous header files
  AArch64: Build infrastructure
  AArch64: MAINTAINERS update

Marc Zyngier (3):
  AArch64: IRQ handling
  AArch64: Miscellaneous library functions
  AArch64: Generic timers support

Will Deacon (8):
  ipc: Add COMPAT_SHMLBA support
  ipc: allow compat IPC version field parsing if
!ARCH_WANT_OLD_COMPAT_IPC
  ipc: compat: use signed size_t types for msgsnd and msgrcv
  AArch64: VDSO support
  AArch64: 32-bit (compat) applications support
  AArch64: Debugging support
  AArch64: Performance counters support
  AArch64: Loadable modules

 Documentation/aarch64/booting.txt   |  139 +++
 Documentation/aarch64/memory.txt|   69 ++
 MAINTAINERS |6 +
 arch/aarch64/Kconfig|  263 +
 arch/aarch64/Kconfig.debug  |   44 +
 arch/aarch64/Makefile   |   71 ++
 arch/aarch64/boot/.gitignore|2 +
 arch/aarch64/boot/Makefile  |   38 +
 arch/aarch64/boot/install.sh|   52 +
 arch/aarch64/include/asm/Kbuild |   50 +
 arch/aarch64/include/asm/asm-offsets.h  |1 +
 arch/aarch64/include/asm/assembler.h|  143 +++
 arch/aarch64/include/asm/atomic.h   |  307 +
 arch/aarch64/include/asm/auxvec.h   |   23 +
 arch/aarch64/include/asm/barrier.h  |   53 +
 arch/aarch64/include/asm/bitops.h   |   75 ++
 arch/aarch64/include/asm/bitsperlong.h  |   24 +
 arch/aarch64/include/asm/byteorder.h|   22 +
 arch/aarch64/include/asm/cache.h|   33 +
 arch/aarch64/include/asm/cacheflush.h   |  210 
 arch/aarch64/include/asm/cachetype.h|   49 +
 arch/aarch64/include/asm/cmpxchg.h  |  181 +++
 arch/aarch64/include/asm/compat.h   |  233 
 arch/aarch64/inc