This came up on debian-devel, and seems like a very cross-distro
thing, albeit not ARM-specific, so reposting here. Anyone here able to
explain/interested in explaining distro-thinking to the C++ standards
people (in San Diego)?
----- Forwarded message from Jussi Pakkanen <jpakkane(a)gmail.com> -----
Date: Wed, 3 Oct 2018 19:56:29 +0300
From: Jussi Pakkanen <jpakkane(a)gmail.com>
To: debian-devel(a)lists.debian.org
Subject: Debian packaging, dependency management and the C++ standards meeting
X-Spam-Status: No, score=-0.2 required=4.0 tests=DKIM_SIGNED,DKIM_VALID,
DKIM_VALID_AU,DKIM_VERIFIED,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE autolearn=no
autolearn_force=no version=3.4.1
List-Id: <debian-devel.lists.debian.org>
Hi
Last week I was at CppCon, which is the biggest C++ developers'
conference in the world. There were a lot of talks about dependencies,
packaging and deployment and other such things related to Debian. A
representative snippet can be seen in this video starting at 1:13:56:
https://www.youtube.com/watch?v=TjdCxXdjaSA
The tl/dr version is that people running the C++ standardisation work
do not really have knowledge about the way Debian does things and
because of this might not take relevant things into consideration. As
an example there is a rising trend of "discard ABI stability, static
link everything and recompile the world on every change" vibe going on
similar to most new system programming languages. This would make
things difficult for Debian due to obvious reasons.
They specifically mention that there is a standardisation meeting next
month (in San Diego?) and that if people from Debian and other groups
underrepresented in the C++ standardisation process were to attend,
they would like to talk to them to understand their requirements. This
specific thing is mentioned in the video at 1:17, the person in the
white shirt answering the question is Titus Winters, Google's C++ lead
(of some sort, don't know the specifics) and he is a big advocate of
static linking everything.
I can't attend due to geographical reasons but would there be someone
who could and would be interested? It would probably be beneficial to
have Debian people there to tell about those specific requirements,
because it seems like most people on the standardisation committee do
not really have a good grasp on what they are. In fact it might make
sense to send distro people in general, since the requirements are
very similar for Red Hat, Ubuntu, SuSE et al. If you have contacts in
those organisations who would be interested in this issue feel free to
send them links to this email thread. I know Red Hat at least has sent
people to the meeting in the past but on the language/stdlib side, not
for packaging (that I know of at least).
An alternative, or parallel, approach could be to write a paper
outlining the issues and submitting it to the standard body. This does
require someone to be physically at the meeting and to present the
paper and its conclusions to the participants and be ready to answer
questions. (I have never actually done this myself, so the above
description might have flaws.) Having a position paper co-signed by
several different distros could be beneficial in making our views
heard.
The downside is that the deadline for submitting papers is fairly
short, I think something like 1.5 weeks so this would need to move
fairly quickly.
Thanks,
(not subscribed to the list so please cc)
----- End forwarded message -----
Wookey
--
Principal hats: Linaro, Debian, Wookware, ARM
http://wookware.org/
When we first ported EDK2 to KVM/arm, we implemented a workaround for
the quirky timer handling on the KVM side. This has been fixed in
Linux commit f120cd6533d2 ("KVM: arm/arm64: timer: Allow the timer to
control the active state") dated 23 June 2014, which was incorporated
into Linux release 4.3.
So almost 4 years later, it should be safe to drop this workaround on
the EDK2 side.
This reverts commit b1a633434ddc.
Cc: cross-distro(a)lists.linaro.org
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ard Biesheuvel <ard.biesheuvel(a)linaro.org>
Acked-by: Marc Zyngier <marc.zyngier(a)arm.com>
Reviewed-by: Leif Lindholm <leif.lindholm(a)linaro.org>
Acked-by: Laszlo Ersek <lersek(a)redhat.com>
---
v2: add acks
Note to cross-distro readers: this means guest firmware built with this patch
will not work on KVM/ARM hosts using kernel v4.2 or earlier.
ArmPkg/Drivers/TimerDxe/TimerDxe.c | 1 -
ArmPkg/Library/ArmGenericTimerVirtCounterLib/ArmGenericTimerVirtCounterLib.c | 10 ----------
2 files changed, 11 deletions(-)
diff --git a/ArmPkg/Drivers/TimerDxe/TimerDxe.c b/ArmPkg/Drivers/TimerDxe/TimerDxe.c
index a3202fa056f3..bd616d2efc73 100644
--- a/ArmPkg/Drivers/TimerDxe/TimerDxe.c
+++ b/ArmPkg/Drivers/TimerDxe/TimerDxe.c
@@ -337,7 +337,6 @@ TimerInterruptHandler (
// Set next compare value
ArmGenericTimerSetCompareVal (CompareValue);
- ArmGenericTimerEnableTimer ();
ArmInstructionSynchronizationBarrier ();
}
diff --git a/ArmPkg/Library/ArmGenericTimerVirtCounterLib/ArmGenericTimerVirtCounterLib.c b/ArmPkg/Library/ArmGenericTimerVirtCounterLib/ArmGenericTimerVirtCounterLib.c
index 69a4ceb62db6..c941895a3574 100644
--- a/ArmPkg/Library/ArmGenericTimerVirtCounterLib/ArmGenericTimerVirtCounterLib.c
+++ b/ArmPkg/Library/ArmGenericTimerVirtCounterLib/ArmGenericTimerVirtCounterLib.c
@@ -26,16 +26,6 @@ ArmGenericTimerEnableTimer (
TimerCtrlReg = ArmReadCntvCtl ();
TimerCtrlReg |= ARM_ARCH_TIMER_ENABLE;
-
- //
- // When running under KVM, we need to unmask the interrupt on the timer side
- // as KVM will mask it when servicing the interrupt at the hypervisor level
- // and delivering the virtual timer interrupt to the guest. Otherwise, the
- // interrupt will fire again, trapping into the hypervisor again, etc. etc.
- // This is scheduled to be fixed on the KVM side, but there is no harm in
- // leaving this in once KVM gets fixed.
- //
- TimerCtrlReg &= ~ARM_ARCH_TIMER_IMASK;
ArmWriteCntvCtl (TimerCtrlReg);
}
--
2.17.0
Hello,
For information, a patch has been posted to the glibc development list:
https://sourceware.org/ml/libc-alpha/2018-04/msg00393.html
which enables searching of "atomics" subdirectories when ld loads
libraries, for systems where 8.1 atomics are enabled.
This should allow one to employ the 8.1 atomics "baked in" to an
optimised self-contained library rather than have to decouple them
with alternative code paths, ifuncs, custom loaders etc.
As an example, with this patch applied and running in a test model
with 8.1 atomics enabled, and a filesystem with an extra libc
supplied; I got the following from /proc/self/maps:
/lib/aarch64-linux-gnu/atomics/libc.so.6
(re-running the model without atomics enabled gave the libc in
/lib/aarch64-linux-gnu/ instead).
Cheers,
--
Steve
= LSE atomics problem =
Large System Extensions, part of ARMv8.1, provides new atomics
instructions. These instructions are essential for high performance
locking when you have lots of cores.
Recommendation: distributions should provide an alternative optimized
glibc with LSE atomics based locks for end users.
= Scalable Vector Extensions =
May have an ABI issue. Situation under investigation.
= Page size =
Don't assume your binaries will always execute in the page size they
were built on. Even if your distribution is built on 4K page size, be
aware that some of your users might opt to run with 64K page size
kernel - for example in containers.
Users be aware, that switching between 4K and 64K kernels may break
some data structures that depend on page size. Swap needs be
reformatted, and btrfs will explode on page size change-
= OCI spec =
With LSE, SVE, armv8.x releases coming, any containers using newer
instructions should be identified in variant field.
= Booting =
One day, booting on arm will be so boring, that nobody will bring it
up on our cross-distribution BoF. That day was not today.
RHEL only supports ACPI on arm64. Even if you are not RHEL, you should
prefer ACPI over device tree, if the former is available.
U-boot can now start EFI binaries, making u-boot an excellent platform
to implement an UEFI bios. This allows single-path installers for
distributions, where install of distribution starts always by loading
grub from EFI.
On arm64, Kernel doesn't self-decompress. The bootloaders are stringly
recommended to support decompressing kernel images. It's optional in
grub, make sure your grub does. At least iPXE and u-boot don't support
booting Image.gz on arm64, and should be fixed.
Riku
Hi,
We'll have the traditional cross-distribution BoF at Linaro connect
Wednesday 27.9, at 3PM US pacific time - 22.00 UTC. We don't have a
set agenda, but if anything is bugging you, replying to this mail is
great way to make it into our topics :)
Riku
hey,
I'm investigating enabling AArch32/Virt edk2 builds in Debian:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=857858
I wanted to see if we can reach a consensus on what the pathname for
these images should be, as these paths for other architectures have
become hardcoded in upstream projects like OpenStack Nova and libvirt.
These project currently expect to find the AArch64 images at:
/usr/share/AAVMF/AAVMF_{CODE,VARS}.fd
And, similarly, the x86-64 images at:
/usr/share/ovmf/OVMF_{CODE,VARS}.fd
I'm unaware of anyone shipping 32-bit x86 images.
I propose:
/usr/share/AAVMF/AAVMF32_{CODE,VARS}.fd
-dann
On Mär 16 2017, Wookey <wookey(a)wookware.org> wrote:
> After feedback from people interested in ILP32, and discussion at
> Linaro Connect, it seems that everyone involved is in agreement that
> the triplets with the 'ilp32' bit in the ABI/OS part rather than the
> machine/cpu part makes more sense. And that we can and should change
> it, so long as it doesn't add significant delay. Thus it was agreed to
> make this change. So the triplet for ilp32 on arm64/aarch64 is now:
>
> aarch64-linux-gnu_ilp32 (normal, little endian)
> aarch64_be-linux-gnu_ilp32 (big endian)
That makes it quite difficult to support building ilp32 packages with
rpm.
Andreas.
--
Andreas Schwab, SUSE Labs, schwab(a)suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4D4 88E3 0EEA B9D7
"And now for something completely different."
Hello all,
Please refer to the patch and the ACPI/arm64 maintainer's reply below
if you are interested in understanding why the SolidRun MacchiatoBin
board (an arm64 board based on the Marvell Armada 8040 SoC) cannot be
fully supported in ACPI mode in the upstream kernel. The change itself
is trivial, but it violates a policy regarding standards compliance
when it comes to implementing the PCIe root complex.
However, this is a very useful board when it comes to development
involving secure and non-secure firmware, given that all the code it
runs is open (ARM Trusted Firmware, U-Boot, UEFI). So perhaps it may
be worth considering taking this as a downstream patch in the distros?
--
Ard.
Forwarded conversation
Subject: [RFC PATCH] acpi/pci: mcfg: add quirk for Marvell Armada8k
------------------------
From: Ard Biesheuvel <ard.biesheuvel(a)linaro.org>
Date: 27 April 2017 at 14:17
To: leif.lindholm(a)linaro.org, graeme.gregory(a)linaro.org
Cc: agraf(a)suse.de, mw(a)semihalf.com, yehuday(a)marvell.com,
linaro-acpi(a)lists.linaro.org, lorenzo.pieralisi(a)arm.com, Ard
Biesheuvel <ard.biesheuvel(a)linaro.org>
This implements a quirk for the Marvell Armada80x0 running in ACPI mode,
in which case the config space configuration is not 100% ECAM compatible.
The issue with this SoC is that it only consists of a host bridge, and
all type 0 configuration cycles are forwarded to the peer (i.e., the
device in the slot), which will therefore appear at all device slots
on bus 0. This can be fixed by reducing the IATU window size for bus 0,
but due to CX_ATU_MIN_REGION_SIZE == 64KB (which is a synthesis-time
configuration parameter of the IP block) the window producing type 0
config cycles will always produce two copies of the peer device.
So add a quirk that specifies a config space accessor override, and
override config space accesses to devices on bus 0 other than device 0.
Signed-off-by: Ard Biesheuvel <ard.biesheuvel(a)linaro.org>
---
drivers/acpi/pci_mcfg.c | 36 ++++++++++++++++++++++++++++++++++++
1 file changed, 36 insertions(+)
diff --git a/drivers/acpi/pci_mcfg.c b/drivers/acpi/pci_mcfg.c
index 2944353253ed..7d68b3208043 100644
--- a/drivers/acpi/pci_mcfg.c
+++ b/drivers/acpi/pci_mcfg.c
@@ -49,6 +49,40 @@ struct mcfg_fixup {
NULL, IORESOURCE_BUS)
#define MCFG_BUS_ANY MCFG_BUS_RANGE(0x0, 0xff)
+/*
+ * The Armada 8k uses Synopsys PCIe IP, which /can/ be configured at
+ * synthesis time to be ECAM compatible, by reducing the IATU minimum
+ * window size to 32 KB. This way, we can reduce the window that produces
+ * type 0 config cycles to only cover b/d 0/0, which will make the peer
+ * only appear once on bus 0. The rest of the ECAM region can be enabled
+ * to generate type 1 config cycles in an ECAM compliant manner, which
+ * makes the rest of the hierarchy accessible if the peer is a true
+ * bridge.
+ *
+ * Note that in this configuration, there is only a host bridge that
+ * translates memory accesses to PCI bus cycles, and given that there
+ * is only a single peer, there is no reason to model a pseudobridge
+ * on bus 0 and make the peer appear on bus 1. (This is how the various
+ * DT drivers for snps,dw-pcie compatible controllers are implemented.)
+ */
+static void __iomem *armada8k_pcie_ecam_map_bus(struct pci_bus *bus,
+ unsigned int devfn,
+ int where)
+{
+ if (bus->number == 0 && PCI_SLOT(devfn) > 0)
+ return NULL;
+ return pci_ecam_map_bus(bus, devfn, where);
+}
+
+static struct pci_ecam_ops armada8k_pcie_ecam_ops = {
+ .bus_shift = 20,
+ .pci_ops = {
+ .map_bus = armada8k_pcie_ecam_map_bus,
+ .read = pci_generic_config_read,
+ .write = pci_generic_config_write,
+ }
+};
+
static struct mcfg_fixup mcfg_quirks[] = {
/* { OEM_ID, OEM_TABLE_ID, REV, SEGMENT, BUS_RANGE, ops, cfgres }, */
@@ -133,6 +167,8 @@ static struct mcfg_fixup mcfg_quirks[] = {
XGENE_V2_ECAM_MCFG(4, 0),
XGENE_V2_ECAM_MCFG(4, 1),
XGENE_V2_ECAM_MCFG(4, 2),
+
+ { "MVEBU ", "ARMADA8K", 0, 0, MCFG_BUS_ANY, &armada8k_pcie_ecam_ops },
};
static char mcfg_oem_id[ACPI_OEM_ID_SIZE];
--
2.9.3
----------
From: Lorenzo Pieralisi <lorenzo.pieralisi(a)arm.com>
Date: 28 April 2017 at 17:14
To: Ard Biesheuvel <ard.biesheuvel(a)linaro.org>
Cc: leif.lindholm(a)linaro.org, graeme.gregory(a)linaro.org,
agraf(a)suse.de, mw(a)semihalf.com, yehuday(a)marvell.com,
linaro-acpi(a)lists.linaro.org
On Thu, Apr 27, 2017 at 02:17:32PM +0100, Ard Biesheuvel wrote:
> This implements a quirk for the Marvell Armada80x0 running in ACPI mode,
> in which case the config space configuration is not 100% ECAM compatible.
Too bad, I am not keen on merging any more ECAM quirks, we have been
very clear about this and it is in our best interest to keep this
code out of tree - we will bootstrap ACPI PCI systems on ECAM HW/FW
compliant systems, that's it (I understand it is painful but it is
necessary).
Thanks,
Lorenzo
I have been working on arm64 ILP32 bootstrapping (in debian) for some
time now (sporadically), and in doing so noticed that we (ARM) did not
choose the best triplet. After internal discussion we have decided
that it would be better if it was changed, if possible. The technical
case for this is set out below.
Changing it is only sensible if there is consensus across distros and
upstreams that this is the right way to go, so comment is being
solicited here. If people have good reasons why it is worth the extra
work and difference from x86 practice involved in keeping the
existing triplet, then we can do that.
The existing triplets (big+little endian) are:
aarch64_ilp32-linux-gnu
aarch64_be_ilp32-linux-gnu
The proposed new triplets are:
aarch64-linux-gnu_ilp32
aarch64_be-linux-gnu_ilp32
The reasoning for changing is as follows.
The main technical argument is:
* ILP32 is an ABI, not a machine/kernel feature. So it makes more
sense to put the ILP32 indicator in the 'ABI' part of the triplet
than the 'kernel/machine' part of the triplet. No kernel will ever
return 'aarch64_ilp32' via uname (only 'aarch64' or 'aarch64_be').
Any aarch64 machine, with a new-enough kernel, can run LP64 or
ILP32 code. The kernel/hardware really doesn't care. Which you
choose/want is a feature of the userspace, more specifically of the
glibc and/or gcc defaults in place, (gcc defaults optionally
overridden with a -mabi option). Thus it makes sense to say "this
userspace is 'gnu_ilp32' ABI", when building/configuring software.
The main practical arguments are:
* We don't have to change config.sub/guess in every autoconfed piece
of software in the world to get our new ABI recognised. To use
aarch64_ilp32-linux-gnu requires config.sub and config.guess to be
updated in every autoconf-using package, and no autoconf update has
even gone upstream yet so this will take years. If we use
aarch64-linux-gnu_ilp32 instead, autoconf 'just works' already without
any changes, as abi suffixes are passed-through.
This is the thing that will significantly reduce the effort of building
an ILP32 userspace.
* The x86 'x32' ABI is exactly analagous to the aarch64 ilp32 ABI,
and they chose to use an ABI suffix: 'x86_64-linux-gnux32'
Avoiding gratuitous difference from x86, in the exact same
situation, without any technical justification for divergence, is
sensible. More stuff should just work, like the autoconf case, or
at least be fixed in the same way, so porting is easier. Being
gratuitously different is both confusing to people and likely to
make more porting work (but I don't have a good handle on how much
more, beyond autoconf-using packages).
We do insist on an '_' separator, because separators are good for
both clarity and parsing. (i.e gnu_ilp32, not gnuilp32)
We realise that it is rather late in the day for this change, as some
people have been using the existing triplet in toolchains already, but
the kernel and glibc ABI was only relatively recently settled and
patches submitted, there is no autoconf support yet upstream, and the
toolchain support is incomplete in that you can't actually build a
self-hosted ilp32-defaulting toolchain yet, so we believe that it is
not actually too late, and worth trying to fix this now in the
interests of a simpler porting process in the long term.
The set of people who actually use ILP32 at this early stage, and thus
care, is currently quite small, but we would like to hear from anyone
who has baked the existing triplet into something and maybe released
it, such that this change could cause serious dificulties? (loader path
is the main place this gets exposed). Are there good reasons why it is
in fact not practical to change to using the new triplet (assuming
that we get on with it reasonably promptly)?
Thank you for reading this far, I look forward to your comments.
Wookey
--
Principal hats: Linaro, Debian, ARM
http://wookware.org/
