All of lore.kernel.org
 help / color / mirror / Atom feed
From: Marc Zyngier <maz@kernel.org>
To: Guenter Roeck <linux@roeck-us.net>
Cc: David Brazdil <dbrazdil@google.com>,
	kvmarm@lists.cs.columbia.edu, Mark Rutland <mark.rutland@arm.com>,
	Suzuki K Poulose <suzuki.poulose@arm.com>,
	Catalin Marinas <catalin.marinas@arm.com>,
	linux-kernel@vger.kernel.org, James Morse <james.morse@arm.com>,
	linux-arm-kernel@lists.infradead.org,
	Will Deacon <will@kernel.org>, Ard Biesheuvel <ardb@kernel.org>,
	Julien Thierry <julien.thierry.kdev@gmail.com>
Subject: Re: [PATCH v2 4/8] KVM: arm64: Generate hyp relocation data
Date: Sat, 30 Jan 2021 12:16:40 +0000	[thread overview]
Message-ID: <a2c65d97fb924bd78aae3cf5659c9adc@kernel.org> (raw)
In-Reply-To: <20210129214325.GA195322@roeck-us.net>

Hi Guenter,

Thanks a lot for the heads up.

On 2021-01-29 21:43, Guenter Roeck wrote:
> Hi,
> 
> On Tue, Jan 05, 2021 at 06:05:37PM +0000, David Brazdil wrote:
>> Add a post-processing step to compilation of KVM nVHE hyp code which
>> calls a custom host tool (gen-hyprel) on the partially linked object
>> file (hyp sections' names prefixed).
>> 
>> The tool lists all R_AARCH64_ABS64 data relocations targeting hyp
>> sections and generates an assembly file that will form a new section
>> .hyp.reloc in the kernel binary. The new section contains an array of
>> 32-bit offsets to the positions targeted by these relocations.
>> 
>> Since these addresses of those positions will not be determined until
>> linking of `vmlinux`, each 32-bit entry carries a R_AARCH64_PREL32
>> relocation with addend <section_base_sym> + <r_offset>. The linker of
>> `vmlinux` will therefore fill the slot accordingly.
>> 
>> This relocation data will be used at runtime to convert the kernel VAs
>> at those positions to hyp VAs.
>> 
>> Signed-off-by: David Brazdil <dbrazdil@google.com>
> 
> This patch results in the following error for me.
> 
> error: arch/arm64/kvm/hyp/nvhe/kvm_nvhe.tmp.o: assertion
> elf.ehdr->e_ident[5] == 1 failed (lhs=2, rhs=1, line=250)
> 
> The problem is seen when trying to build aarch64 images in big endian
> mode.

Ah, big-endian. of course, the ELF header is in native endianness,
and the sanity checks explode (still much better than generating crap).

I'll have a look shortly. It shouldn't too hard to fix, just a
bit invasive...

Thanks again,

         M.
-- 
Jazz is not dead. It just smells funny...

WARNING: multiple messages have this Message-ID (diff)
From: Marc Zyngier <maz@kernel.org>
To: Guenter Roeck <linux@roeck-us.net>
Cc: Catalin Marinas <catalin.marinas@arm.com>,
	linux-kernel@vger.kernel.org, Ard Biesheuvel <ardb@kernel.org>,
	Will Deacon <will@kernel.org>,
	kvmarm@lists.cs.columbia.edu,
	linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH v2 4/8] KVM: arm64: Generate hyp relocation data
Date: Sat, 30 Jan 2021 12:16:40 +0000	[thread overview]
Message-ID: <a2c65d97fb924bd78aae3cf5659c9adc@kernel.org> (raw)
In-Reply-To: <20210129214325.GA195322@roeck-us.net>

Hi Guenter,

Thanks a lot for the heads up.

On 2021-01-29 21:43, Guenter Roeck wrote:
> Hi,
> 
> On Tue, Jan 05, 2021 at 06:05:37PM +0000, David Brazdil wrote:
>> Add a post-processing step to compilation of KVM nVHE hyp code which
>> calls a custom host tool (gen-hyprel) on the partially linked object
>> file (hyp sections' names prefixed).
>> 
>> The tool lists all R_AARCH64_ABS64 data relocations targeting hyp
>> sections and generates an assembly file that will form a new section
>> .hyp.reloc in the kernel binary. The new section contains an array of
>> 32-bit offsets to the positions targeted by these relocations.
>> 
>> Since these addresses of those positions will not be determined until
>> linking of `vmlinux`, each 32-bit entry carries a R_AARCH64_PREL32
>> relocation with addend <section_base_sym> + <r_offset>. The linker of
>> `vmlinux` will therefore fill the slot accordingly.
>> 
>> This relocation data will be used at runtime to convert the kernel VAs
>> at those positions to hyp VAs.
>> 
>> Signed-off-by: David Brazdil <dbrazdil@google.com>
> 
> This patch results in the following error for me.
> 
> error: arch/arm64/kvm/hyp/nvhe/kvm_nvhe.tmp.o: assertion
> elf.ehdr->e_ident[5] == 1 failed (lhs=2, rhs=1, line=250)
> 
> The problem is seen when trying to build aarch64 images in big endian
> mode.

Ah, big-endian. of course, the ELF header is in native endianness,
and the sanity checks explode (still much better than generating crap).

I'll have a look shortly. It shouldn't too hard to fix, just a
bit invasive...

Thanks again,

         M.
-- 
Jazz is not dead. It just smells funny...
_______________________________________________
kvmarm mailing list
kvmarm@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm

WARNING: multiple messages have this Message-ID (diff)
From: Marc Zyngier <maz@kernel.org>
To: Guenter Roeck <linux@roeck-us.net>
Cc: Mark Rutland <mark.rutland@arm.com>,
	Suzuki K Poulose <suzuki.poulose@arm.com>,
	Catalin Marinas <catalin.marinas@arm.com>,
	linux-kernel@vger.kernel.org, Ard Biesheuvel <ardb@kernel.org>,
	James Morse <james.morse@arm.com>,
	Julien Thierry <julien.thierry.kdev@gmail.com>,
	David Brazdil <dbrazdil@google.com>,
	Will Deacon <will@kernel.org>,
	kvmarm@lists.cs.columbia.edu,
	linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH v2 4/8] KVM: arm64: Generate hyp relocation data
Date: Sat, 30 Jan 2021 12:16:40 +0000	[thread overview]
Message-ID: <a2c65d97fb924bd78aae3cf5659c9adc@kernel.org> (raw)
In-Reply-To: <20210129214325.GA195322@roeck-us.net>

Hi Guenter,

Thanks a lot for the heads up.

On 2021-01-29 21:43, Guenter Roeck wrote:
> Hi,
> 
> On Tue, Jan 05, 2021 at 06:05:37PM +0000, David Brazdil wrote:
>> Add a post-processing step to compilation of KVM nVHE hyp code which
>> calls a custom host tool (gen-hyprel) on the partially linked object
>> file (hyp sections' names prefixed).
>> 
>> The tool lists all R_AARCH64_ABS64 data relocations targeting hyp
>> sections and generates an assembly file that will form a new section
>> .hyp.reloc in the kernel binary. The new section contains an array of
>> 32-bit offsets to the positions targeted by these relocations.
>> 
>> Since these addresses of those positions will not be determined until
>> linking of `vmlinux`, each 32-bit entry carries a R_AARCH64_PREL32
>> relocation with addend <section_base_sym> + <r_offset>. The linker of
>> `vmlinux` will therefore fill the slot accordingly.
>> 
>> This relocation data will be used at runtime to convert the kernel VAs
>> at those positions to hyp VAs.
>> 
>> Signed-off-by: David Brazdil <dbrazdil@google.com>
> 
> This patch results in the following error for me.
> 
> error: arch/arm64/kvm/hyp/nvhe/kvm_nvhe.tmp.o: assertion
> elf.ehdr->e_ident[5] == 1 failed (lhs=2, rhs=1, line=250)
> 
> The problem is seen when trying to build aarch64 images in big endian
> mode.

Ah, big-endian. of course, the ELF header is in native endianness,
and the sanity checks explode (still much better than generating crap).

I'll have a look shortly. It shouldn't too hard to fix, just a
bit invasive...

Thanks again,

         M.
-- 
Jazz is not dead. It just smells funny...

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

  reply	other threads:[~2021-01-30 12:17 UTC|newest]

Thread overview: 57+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-01-05 18:05 [PATCH v2 0/8] arm64: Relocate absolute hyp VAs David Brazdil
2021-01-05 18:05 ` David Brazdil
2021-01-05 18:05 ` David Brazdil
2021-01-05 18:05 ` [PATCH v2 1/8] KVM: arm64: Rename .idmap.text in hyp linker script David Brazdil
2021-01-05 18:05   ` David Brazdil
2021-01-05 18:05   ` David Brazdil
2021-01-05 18:05 ` [PATCH v2 2/8] KVM: arm64: Set up .hyp.rodata ELF section David Brazdil
2021-01-05 18:05   ` David Brazdil
2021-01-05 18:05   ` David Brazdil
2021-01-05 18:05 ` [PATCH v2 3/8] KVM: arm64: Add symbol at the beginning of each hyp section David Brazdil
2021-01-05 18:05   ` David Brazdil
2021-01-05 18:05   ` David Brazdil
2021-01-23 13:30   ` Marc Zyngier
2021-01-23 13:30     ` Marc Zyngier
2021-01-23 13:30     ` Marc Zyngier
2021-01-05 18:05 ` [PATCH v2 4/8] KVM: arm64: Generate hyp relocation data David Brazdil
2021-01-05 18:05   ` David Brazdil
2021-01-05 18:05   ` David Brazdil
2021-01-29 21:43   ` Guenter Roeck
2021-01-29 21:43     ` Guenter Roeck
2021-01-29 21:43     ` Guenter Roeck
2021-01-30 12:16     ` Marc Zyngier [this message]
2021-01-30 12:16       ` Marc Zyngier
2021-01-30 12:16       ` Marc Zyngier
2021-01-30 13:44     ` Marc Zyngier
2021-01-30 13:44       ` Marc Zyngier
2021-01-30 13:44       ` Marc Zyngier
2021-01-30 16:11       ` Guenter Roeck
2021-01-30 16:11         ` Guenter Roeck
2021-01-30 16:11         ` Guenter Roeck
2021-01-30 18:10         ` Marc Zyngier
2021-01-30 18:10           ` Marc Zyngier
2021-01-30 18:10           ` Marc Zyngier
2021-02-01 10:42       ` David Brazdil
2021-02-01 10:42         ` David Brazdil
2021-02-01 10:42         ` David Brazdil
2021-02-01 12:06         ` Marc Zyngier
2021-02-01 12:06           ` Marc Zyngier
2021-02-01 12:06           ` Marc Zyngier
2021-01-05 18:05 ` [PATCH v2 5/8] KVM: arm64: Apply hyp relocations at runtime David Brazdil
2021-01-05 18:05   ` David Brazdil
2021-01-05 18:05   ` David Brazdil
2021-01-05 18:05 ` [PATCH v2 6/8] KVM: arm64: Fix constant-pool users in hyp David Brazdil
2021-01-05 18:05   ` David Brazdil
2021-01-05 18:05   ` David Brazdil
2021-01-05 18:05 ` [PATCH v2 7/8] KVM: arm64: Remove patching of fn pointers " David Brazdil
2021-01-05 18:05   ` David Brazdil
2021-01-05 18:05   ` David Brazdil
2021-01-05 18:05 ` [PATCH v2 8/8] KVM: arm64: Remove hyp_symbol_addr David Brazdil
2021-01-05 18:05   ` David Brazdil
2021-01-05 18:05   ` David Brazdil
2021-01-23 13:54   ` Marc Zyngier
2021-01-23 13:54     ` Marc Zyngier
2021-01-23 13:54     ` Marc Zyngier
2021-01-23 14:45 ` [PATCH v2 0/8] arm64: Relocate absolute hyp VAs Marc Zyngier
2021-01-23 14:45   ` Marc Zyngier
2021-01-23 14:45   ` Marc Zyngier

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=a2c65d97fb924bd78aae3cf5659c9adc@kernel.org \
    --to=maz@kernel.org \
    --cc=ardb@kernel.org \
    --cc=catalin.marinas@arm.com \
    --cc=dbrazdil@google.com \
    --cc=james.morse@arm.com \
    --cc=julien.thierry.kdev@gmail.com \
    --cc=kvmarm@lists.cs.columbia.edu \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux@roeck-us.net \
    --cc=mark.rutland@arm.com \
    --cc=suzuki.poulose@arm.com \
    --cc=will@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.