All of lore.kernel.org
 help / color / mirror / Atom feed
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Marc Zyngier <marc.zyngier@arm.com>
Cc: kvm@vger.kernel.org, Catalin Marinas <catalin.marinas@arm.com>,
	Will Deacon <will.deacon@arm.com>,
	linux-arm-kernel@lists.infradead.org,
	kvmarm@lists.cs.columbia.edu
Subject: Re: [PATCH 04/18] arm64: alternatives: Enforce alignment of struct alt_instr
Date: Wed, 6 Dec 2017 10:18:56 -0500	[thread overview]
Message-ID: <20171206151856.GH28074@char.us.oracle.com> (raw)
In-Reply-To: <dd8995ce-3065-3aba-2d93-9ed91de5cd50@arm.com>

On Wed, Dec 06, 2017 at 02:57:29PM +0000, Marc Zyngier wrote:
> On 06/12/17 14:48, Konrad Rzeszutek Wilk wrote:
> > On Wed, Dec 06, 2017 at 02:38:25PM +0000, Marc Zyngier wrote:
> >> We're playing a dangerous game with struct alt_instr, as we produce
> >> it using assembly tricks, but parse them using the C structure.
> >> We just assume that the respective alignments of the two will
> >> be the same.
> >>
> >> But as we add more fields to this structure, the alignment requirements
> >> of the structure may change, and lead to all kind of funky bugs.
> >>
> >> TO solve this, let's move the definition of struct alt_instr to its
> >> own file, and use this to generate the alignment constraint from
> >> asm-offsets.c. The various macros are then patched to take the
> >> alignment into account.
> > 
> > Would it be better to use .p2align as on 32-bit ARM you must
> > have it 4-byte aligned. Or at least have and BUILD_BUG_ON
> > to make sure the size can be divided by four??
> > 
> > Oh wait. You are not even touching ARM-32, how come? The alternative
> > code can run on ARM-32 ...
> 
> How? Given that I haven't written yet, I'd be grateful if you could
> share your time machine...

Oh! I assumed it would be there as the Xen variant runs on ARM-32 and
it borrowed a bunch of code from Linux. 

Please disregard my comment. I will go back to tweaking the time machine.
> 
> Thanks,
> 
> 	M.
> -- 
> Jazz is not dead. It just smells funny...

WARNING: multiple messages have this Message-ID (diff)
From: konrad.wilk@oracle.com (Konrad Rzeszutek Wilk)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 04/18] arm64: alternatives: Enforce alignment of struct alt_instr
Date: Wed, 6 Dec 2017 10:18:56 -0500	[thread overview]
Message-ID: <20171206151856.GH28074@char.us.oracle.com> (raw)
In-Reply-To: <dd8995ce-3065-3aba-2d93-9ed91de5cd50@arm.com>

On Wed, Dec 06, 2017 at 02:57:29PM +0000, Marc Zyngier wrote:
> On 06/12/17 14:48, Konrad Rzeszutek Wilk wrote:
> > On Wed, Dec 06, 2017 at 02:38:25PM +0000, Marc Zyngier wrote:
> >> We're playing a dangerous game with struct alt_instr, as we produce
> >> it using assembly tricks, but parse them using the C structure.
> >> We just assume that the respective alignments of the two will
> >> be the same.
> >>
> >> But as we add more fields to this structure, the alignment requirements
> >> of the structure may change, and lead to all kind of funky bugs.
> >>
> >> TO solve this, let's move the definition of struct alt_instr to its
> >> own file, and use this to generate the alignment constraint from
> >> asm-offsets.c. The various macros are then patched to take the
> >> alignment into account.
> > 
> > Would it be better to use .p2align as on 32-bit ARM you must
> > have it 4-byte aligned. Or at least have and BUILD_BUG_ON
> > to make sure the size can be divided by four??
> > 
> > Oh wait. You are not even touching ARM-32, how come? The alternative
> > code can run on ARM-32 ...
> 
> How? Given that I haven't written yet, I'd be grateful if you could
> share your time machine...

Oh! I assumed it would be there as the Xen variant runs on ARM-32 and
it borrowed a bunch of code from Linux. 

Please disregard my comment. I will go back to tweaking the time machine.
> 
> Thanks,
> 
> 	M.
> -- 
> Jazz is not dead. It just smells funny...

  reply	other threads:[~2017-12-06 15:15 UTC|newest]

Thread overview: 46+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-12-06 14:38 [PATCH 00/18] KVM/arm64: Randomise EL2 mappings Marc Zyngier
2017-12-06 14:38 ` Marc Zyngier
2017-12-06 14:38 ` [PATCH 01/18] arm64: asm-offsets: Avoid clashing DMA definitions Marc Zyngier
2017-12-06 14:38   ` Marc Zyngier
2017-12-06 14:38 ` [PATCH 02/18] arm64: asm-offsets: Remove unused definitions Marc Zyngier
2017-12-06 14:38   ` Marc Zyngier
2017-12-06 14:38 ` [PATCH 03/18] arm64: asm-offsets: Remove potential circular dependency Marc Zyngier
2017-12-06 14:38   ` Marc Zyngier
2017-12-06 14:38 ` [PATCH 04/18] arm64: alternatives: Enforce alignment of struct alt_instr Marc Zyngier
2017-12-06 14:38   ` Marc Zyngier
2017-12-06 14:48   ` Konrad Rzeszutek Wilk
2017-12-06 14:48     ` Konrad Rzeszutek Wilk
2017-12-06 14:57     ` Marc Zyngier
2017-12-06 14:57       ` Marc Zyngier
2017-12-06 15:18       ` Konrad Rzeszutek Wilk [this message]
2017-12-06 15:18         ` Konrad Rzeszutek Wilk
2017-12-06 15:39         ` Marc Zyngier
2017-12-06 15:39           ` Marc Zyngier
2017-12-06 14:38 ` [PATCH 05/18] arm64: alternatives: Add dynamic patching feature Marc Zyngier
2017-12-06 14:38   ` Marc Zyngier
2017-12-06 14:38 ` [PATCH 06/18] arm64: insn: Add N immediate encoding Marc Zyngier
2017-12-06 14:38   ` Marc Zyngier
2017-12-06 14:38 ` [PATCH 07/18] arm64: insn: Add encoder for bitwise operations using litterals Marc Zyngier
2017-12-06 14:38   ` Marc Zyngier
2017-12-06 14:38 ` [PATCH 08/18] arm64: KVM: Dynamically patch the kernel/hyp VA mask Marc Zyngier
2017-12-06 14:38   ` Marc Zyngier
2017-12-06 14:38 ` [PATCH 09/18] arm64: cpufeatures: Drop the ARM64_HYP_OFFSET_LOW feature flag Marc Zyngier
2017-12-06 14:38   ` Marc Zyngier
2017-12-06 14:38 ` [PATCH 10/18] arm64; insn: Add encoder for the EXTR instruction Marc Zyngier
2017-12-06 14:38   ` Marc Zyngier
2017-12-06 14:38 ` [PATCH 11/18] arm64: insn: Allow ADD/SUB (immediate) with LSL #12 Marc Zyngier
2017-12-06 14:38   ` Marc Zyngier
2017-12-06 14:38 ` [PATCH 12/18] arm64: KVM: Introduce EL2 VA randomisation Marc Zyngier
2017-12-06 14:38   ` Marc Zyngier
2017-12-06 14:38 ` [PATCH 13/18] arm64: Update the KVM memory map documentation Marc Zyngier
2017-12-06 14:38   ` Marc Zyngier
2017-12-06 14:38 ` [PATCH 14/18] KVM: arm/arm64: Do not use kern_hyp_va() with kvm_vgic_global_state Marc Zyngier
2017-12-06 14:38   ` Marc Zyngier
2017-12-06 14:38 ` [PATCH 15/18] KVM: arm/arm64: Demote HYP VA range display to being a debug feature Marc Zyngier
2017-12-06 14:38   ` Marc Zyngier
2017-12-06 14:38 ` [PATCH 16/18] KVM: arm/arm64: Move ioremap calls to create_hyp_io_mappings Marc Zyngier
2017-12-06 14:38   ` Marc Zyngier
2017-12-06 14:38 ` [PATCH 17/18] KVM: arm/arm64: Keep GICv2 HYP VAs in kvm_vgic_global_state Marc Zyngier
2017-12-06 14:38   ` Marc Zyngier
2017-12-06 14:38 ` [PATCH 18/18] KVM: arm/arm64: Move HYP IO VAs to the "idmap" range Marc Zyngier
2017-12-06 14:38   ` 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=20171206151856.GH28074@char.us.oracle.com \
    --to=konrad.wilk@oracle.com \
    --cc=catalin.marinas@arm.com \
    --cc=kvm@vger.kernel.org \
    --cc=kvmarm@lists.cs.columbia.edu \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=marc.zyngier@arm.com \
    --cc=will.deacon@arm.com \
    /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.