[Pkg-xen-devel] [PATCH 0/9] RESEND: Fixing cross-compilation, some script work

[Hans van Kranenburg]

Hi!

On 11/27/20 1:43 AM, Elliott Mitchell wrote:
> Resending this batch again, since the updates are still waiting for some
> action.  Plus resending the extras which appear to distinctly improve
> things.

Yes, now that the whole FTBFS circus is solved and there's finally
something in testing/unstable, we can start to import/make more changes
again.

> My pick list has been lengthening.  The first two are very worthwhile for
> Debian.  The first is valuable for one rather popular platform.  That
> platform is sufficiently popular so as to generate large numbers of
> duplicate bug reports for things which effect it.  The second is a piece
> of the cross-compilation fixing which was appropriate to push upstream,
> thus it has been.
> 
> The last bit for (apparently) working cross-compilation is the patch
> included on my message under "Bug#975062".  That bit of scripting is
> rather gross, but it does cover an issue.  I *really* hope there is a
> better fix, but that is how far I've gotten it.  A proper version should
> likely be pushed to upstream.
> 
> The rest are for fixing ARM ACPI support.  There is a functioning
> Tianocore build for that popular platform and these together allow Xen
> to boot on Tianocore on that platform.  Needs an up to date 5.9 kernel
> and graphical output doesn't yet work, but it does boot and can function
> as a low-end server.

Ok, thanks for doing upstream-first. It's no problem to pick a carefully
chosen feature set if it helps you and if we already know that we're
gonna get rid of the exact patches later. :)

> 25849c8b16f2a5b7fcd0a823e80a5f1b590291f9
"xen/rpi4: implement watchdog-based reset"

> 17d192e0238d6c714e9f04593b59597b7090be38
"tools/python: Pass linker to Python build process"

This one does not apply cleanly, but that's because of our make file
patches. It's ok, since we would run into the same thing when moving to
4.15 anyway.

You might want to triple check what I have done here... After a few
minutes, it's too easy to keep staring at it and not see some small mistake.

> 861f0c110976fa8879b7bf63d9478b6be83d4ab6
"xen/arm: acpi: Don't fail if SPCR table is absent"

> 1c4aa69ca1e1fad20b2158051eb152276d1eb973
"xen/acpi: Rework acpi_os_map_memory() and acpi_os_unmap_memory()"

> 4d625ff3c3a939dc270b03654337568c30c5ab6e
"xen/arm: acpi: The fixmap area should always be cleared during
failure/unmap"

> dac867bf9adc1562a4cf9db5f89726597af13ef8
"xen/arm: Check if the platform is not using ACPI before initializing
Dom0less"

> 9c2bc0f24b2ba7082df408b3c33ec9a86bf20cf0
"xen/arm: Introduce fw_unreserved_regions() and use it"

> 7056f2f89f03f2f804ac7e776c7b2b000cd716cd
"xen/arm: acpi: add BAD_MADT_GICC_ENTRY() macro"

> 957708c2d1ae25d7375abd5e5e70c3043d64f1f1
"xen/arm: traps: Don't panic when receiving an unknown debug trap"

Picked and pushed to knorrie/sid branch.

> Yes, I'm including some shell script optimization.  I doubt these speed
> the build that much, but a bunch of small steps together can result in
> large gains.  `set -o pipefail` may be a substantial reliability gain
> when using large, complex pipes with bash; but simplifying those pipes
> results in larger reliability gains.  Notice before that pipe was 20
> lines long and included advanced commands.  After it is merely 8 lines
> plus `grep` and `strings` won't fail (unlike `ldd`).
> 
> `xl` and some of the other utilities wrapped by `xen-utils-wrapper` are
> used repeatedly in many places.  At which point removing most of the
> commands which produce forks from `xen-utils-wrapper` is a very large
> gain.  On a system of mine `/etc/init.d/xendomains start` appeared to use
> roughly 500 processes per domain restored, with the optimization that
> drops to 100 per domain restored.
> 
> Then using an internal xen() wrapper results in further gains.  I haven't
> found anything beside `/etc/init.d/xendomains` using the `xen` wrapper,
> but just in case I left that in place.
> 
> 
> For systems where the xen-acpi-processor kernel module is available,
> enabling that can be substantial savings.  Right now that is
> i386/amd64-only, but I suspect it may get ported to ARM in the future.
> For reference, on a memory-constrained machine of mine `sensors` was
> showing the processor idle at 100W of power without xen-acpi-processor,
> and with xen-acpi-processor it was idling below 30W.

Thanks. I will try to review the rest. I might ask some smarter or
dumber questions in the process to understand the changes, but for me
it's also nice to learn a few new things.

> Elliott Mitchell (9):
>   Rework "debian/rules: Do not try to move EFI binaries on armhf"
>   debian/rules: Correct shim install step for current Xen
>   d/shuffle-binaries: Fix binary shuffling script for cross-building
>   d/shuffle-boot-files: Rework boot shuffling script
>   debian/rules: Set CC/LD for cross-building
>   debian/rules: Setup use of noOCAML profile
>   debian/xen.init: Load xen_acpi_processor on boot
>   debian/scripts: Optimize runtime scripts
>   d/xendomains.init: Remove use of `xen` compat wrapper for `xl`
> 
>  debian/control                          |  5 +--
>  debian/rules                            | 34 ++++++++++++------
>  debian/scripts/xen-utils-wrapper        | 43 ++++++++++++++++++++---
>  debian/scripts/xen-version              |  6 ++--
>  debian/shuffle-binaries                 | 46 ++++++++++++++-----------
>  debian/shuffle-boot-files               | 26 +++++++-------
>  debian/xen-utils-common.xen.init        |  1 +
>  debian/xen-utils-common.xendomains.init |  5 +++
>  8 files changed, 114 insertions(+), 52 deletions(-)

Hans