All of lore.kernel.org
 help / color / mirror / Atom feed
From: Steve Capper <Steve.Capper@arm.com>
To: Marc Zyngier <Marc.Zyngier@arm.com>
Cc: "crecklin@redhat.com" <crecklin@redhat.com>,
	"ard.biesheuvel@linaro.org" <ard.biesheuvel@linaro.org>,
	Catalin Marinas <Catalin.Marinas@arm.com>,
	"bhsharma@redhat.com" <bhsharma@redhat.com>,
	Will Deacon <Will.Deacon@arm.com>, nd <nd@arm.com>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>
Subject: Re: [PATCH v2 01/12] arm/arm64: KVM: Formalise end of direct linear map
Date: Wed, 29 May 2019 09:26:26 +0000	[thread overview]
Message-ID: <20190529092616.GA7196@capper-debian.cambridge.arm.com> (raw)
In-Reply-To: <20190528170116.GA13287@capper-debian.cambridge.arm.com>

On Tue, May 28, 2019 at 05:01:29PM +0000, Steve Capper wrote:
> On Tue, May 28, 2019 at 05:27:17PM +0100, Marc Zyngier wrote:
> > Hi Steve,
> 
> Hi Marc,
> 
> > 
> > On 28/05/2019 17:10, Steve Capper wrote:
> > > We assume that the direct linear map ends at ~0 in the KVM HYP map
> > 
> > Do we? This has stopped being the case since ed57cac83e05f ("arm64: KVM:
> > Introduce EL2 VA randomisation").
> > 
> > > intersection checking code. This assumption will become invalid later on
> > > for arm64 when the address space of the kernel is re-arranged.
> > > 
> > > This patch introduces a new constant PAGE_OFFSET_END for both arm and
> > > arm64 and defines it to be ~0UL
> > > 
> > > Signed-off-by: Steve Capper <steve.capper@arm.com>
> > > ---
> > >  arch/arm/include/asm/memory.h   | 1 +
> > >  arch/arm64/include/asm/memory.h | 1 +
> > >  virt/kvm/arm/mmu.c              | 4 ++--
> > >  3 files changed, 4 insertions(+), 2 deletions(-)
> > > 
> > > diff --git a/arch/arm/include/asm/memory.h b/arch/arm/include/asm/memory.h
> > > index ed8fd0d19a3e..45c211fd50da 100644
> > > --- a/arch/arm/include/asm/memory.h
> > > +++ b/arch/arm/include/asm/memory.h
> > > @@ -24,6 +24,7 @@
> > >  
> > >  /* PAGE_OFFSET - the virtual address of the start of the kernel image */
> > >  #define PAGE_OFFSET		UL(CONFIG_PAGE_OFFSET)
> > > +#define PAGE_OFFSET_END		(~0UL)
> > >  
> > >  #ifdef CONFIG_MMU
> > >  
> > > diff --git a/arch/arm64/include/asm/memory.h b/arch/arm64/include/asm/memory.h
> > > index 8ffcf5a512bb..9fd387a63b9b 100644
> > > --- a/arch/arm64/include/asm/memory.h
> > > +++ b/arch/arm64/include/asm/memory.h
> > > @@ -52,6 +52,7 @@
> > >  	(UL(1) << VA_BITS) + 1)
> > >  #define PAGE_OFFSET		(UL(0xffffffffffffffff) - \
> > >  	(UL(1) << (VA_BITS - 1)) + 1)
> > > +#define PAGE_OFFSET_END		(~0UL)
> > >  #define KIMAGE_VADDR		(MODULES_END)
> > >  #define BPF_JIT_REGION_START	(VA_START + KASAN_SHADOW_SIZE)
> > >  #define BPF_JIT_REGION_SIZE	(SZ_128M)
> > > diff --git a/virt/kvm/arm/mmu.c b/virt/kvm/arm/mmu.c
> > > index 74b6582eaa3c..e1a777275b37 100644
> > > --- a/virt/kvm/arm/mmu.c
> > > +++ b/virt/kvm/arm/mmu.c
> > > @@ -2202,10 +2202,10 @@ int kvm_mmu_init(void)
> > >  	kvm_debug("IDMAP page: %lx\n", hyp_idmap_start);
> > >  	kvm_debug("HYP VA range: %lx:%lx\n",
> > >  		  kern_hyp_va(PAGE_OFFSET),
> > > -		  kern_hyp_va((unsigned long)high_memory - 1));
> > > +		  kern_hyp_va(PAGE_OFFSET_END));
> > >  
> > >  	if (hyp_idmap_start >= kern_hyp_va(PAGE_OFFSET) &&
> > > -	    hyp_idmap_start <  kern_hyp_va((unsigned long)high_memory - 1) &&
> > > +	    hyp_idmap_start <  kern_hyp_va(PAGE_OFFSET_END) &&
> > >  	    hyp_idmap_start != (unsigned long)__hyp_idmap_text_start) {
> > >  		/*
> > >  		 * The idmap page is intersecting with the VA space,
> > > 
> > 
> > This definitely looks like a move in the wrong direction (reverting part
> > of the above commit). Is it that this is just an old patch that should
> > have been dropped? Or am I completely missing the point?
> 
> I suspect this is a case of me rebasing my series... poorly.
> I'll re-examine the logic here and either update the patch or the commit
> log to make it clearer.
>

Hi Marc,
Thanks, this was indeed an overzealous rebase. I've removed this patch from the
series and kvmtool is happy booting guests (when rebased to v5.2-rc2).

Cheers,
-- 
Steve

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

  reply	other threads:[~2019-05-29  9:26 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-05-28 16:10 [PATCH v2 00/12] 52-bit kernel + user VAs Steve Capper
2019-05-28 16:10 ` [PATCH v2 01/12] arm/arm64: KVM: Formalise end of direct linear map Steve Capper
2019-05-28 16:27   ` Marc Zyngier
2019-05-28 17:01     ` Steve Capper
2019-05-29  9:26       ` Steve Capper [this message]
2019-05-28 16:10 ` [PATCH v2 02/12] arm64: mm: Flip kernel VA space Steve Capper
2019-05-28 16:10 ` [PATCH v2 03/12] arm64: kasan: Switch to using KASAN_SHADOW_OFFSET Steve Capper
2019-05-28 16:10 ` [PATCH v2 04/12] arm64: mm: Replace fixed map BUILD_BUG_ON's with BUG_ON's Steve Capper
2019-05-28 17:07   ` Ard Biesheuvel
2019-05-28 17:11     ` Ard Biesheuvel
2019-05-29  9:28       ` Steve Capper
2019-05-28 16:10 ` [PATCH v2 05/12] arm64: dump: Make kernel page table dumper dynamic again Steve Capper
2019-05-28 16:10 ` [PATCH v2 06/12] arm64: mm: Introduce VA_BITS_MIN Steve Capper
2019-05-28 16:10 ` [PATCH v2 07/12] arm64: mm: Introduce VA_BITS_ACTUAL Steve Capper
2019-05-28 16:10 ` [PATCH v2 08/12] arm64: mm: Logic to make offset_ttbr1 conditional Steve Capper
2019-06-10 14:18   ` Catalin Marinas
2019-06-12 10:58     ` Steve Capper
2019-05-28 16:10 ` [PATCH v2 09/12] arm64: mm: Separate out vmemmap Steve Capper
2019-05-28 16:10 ` [PATCH v2 10/12] arm64: mm: Modify calculation of VMEMMAP_SIZE Steve Capper
2019-05-28 16:10 ` [PATCH v2 11/12] arm64: mm: Tweak PAGE_OFFSET logic Steve Capper
2019-05-28 16:10 ` [PATCH v2 12/12] arm64: mm: Introduce 52-bit Kernel VAs Steve Capper
2019-06-05 15:34   ` Catalin Marinas
2019-06-07 10:34     ` Steve Capper
2019-06-07 13:53 ` [PATCH v2 00/12] 52-bit kernel + user VAs Anshuman Khandual
2019-06-07 14:24   ` Steve Capper
2019-06-10 10:40 ` Bhupesh Sharma
2019-06-10 10:40   ` Bhupesh Sharma
2019-06-10 10:54   ` Catalin Marinas
2019-06-10 10:54     ` Catalin Marinas
2019-06-10 11:15     ` Bhupesh Sharma
2019-06-10 11:15       ` Bhupesh Sharma

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=20190529092616.GA7196@capper-debian.cambridge.arm.com \
    --to=steve.capper@arm.com \
    --cc=Catalin.Marinas@arm.com \
    --cc=Marc.Zyngier@arm.com \
    --cc=Will.Deacon@arm.com \
    --cc=ard.biesheuvel@linaro.org \
    --cc=bhsharma@redhat.com \
    --cc=crecklin@redhat.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=nd@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.