qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [Qemu-arm] [PATCH 1/3] target/arm: fix AArch64 virtual


From: Rémi Denis-Courmont
Subject: Re: [Qemu-devel] [Qemu-arm] [PATCH 1/3] target/arm: fix AArch64 virtual address space size
Date: Sat, 26 Jan 2019 08:36:00 +0200

        Hi,

Le lauantaina 26. tammikuuta 2019, 1.29.27 EET Richard Henderson a écrit :
> On 1/25/19 1:49 PM, Rémi Denis-Courmont wrote:
> > From: Remi Denis-Courmont <address@hidden>
> > 
> > Since QEMU does not support the ARMv8.2-LVA, Large Virtual Address,
> > extension (yet), the VA address space is signed 48-bits. User mode can
> > only handle the positive half of the address space, so that makes a
> > limit of 47 bits.
> > 
> > (With LVA, it would be 52 and 51 bits respectively.)
> > 
> > The incorrectly large address space conflicts with PAuth instructions,
> > which bits 48-54 and 56-63 for the pointer authentication code. This
> > also conflicts with (as yet unsupported by QEMU) data tagging and with
> > the ARMv8.5-MTE extension.
> > 
> > Signed-off-by: Remi Denis-Courmont <address@hidden>
> > ---
> > 
> >  target/arm/cpu.h | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> > 
> > diff --git a/target/arm/cpu.h b/target/arm/cpu.h
> > index ff81db420d..2ccd04b8f7 100644
> > --- a/target/arm/cpu.h
> > +++ b/target/arm/cpu.h
> > @@ -2503,7 +2503,7 @@ bool write_cpustate_to_list(ARMCPU *cpu);
> > 
> >  #if defined(TARGET_AARCH64)
> >  #  define TARGET_PHYS_ADDR_SPACE_BITS 48
> > 
> > -#  define TARGET_VIRT_ADDR_SPACE_BITS 64
> > +#  define TARGET_VIRT_ADDR_SPACE_BITS 47
> > 
> >  #else
> >  #  define TARGET_PHYS_ADDR_SPACE_BITS 40
> >  #  define TARGET_VIRT_ADDR_SPACE_BITS 32
> 
> This doesn't really conflict, as this doesn't affect much besides the sizing
> of the PageDesc for page_find.

Uh, that value controls the range of target virtual addresses user mode maps 
to host virtual addresses. Without this patch, AFAICT, there are no 
guarantees, only chance, that emulated system calls such as mmap() will not 
allocate architecturally invalid addresses.

> It's true adjusting this is worthwhile.  The current setting requires 7
> levels (6 * 10 bits + 1 * 4 bits), whereas a 48-bit address space only
> requires 5 levels (4 * 10 bits + 8 bits).  Even for LVA it will be (4 * 10
> + 1 * 12 bits).

LVA only works with 64 KiB page size and user mode forces 4 KiB page size at 
the moment. And I somewhat doubt that somebody would ever need LVA in QEMU 
user mode. So that's highly hypothetical.

> This will both save memory and reduce the time required for TranlationBlock
> maintenance.
> 
> Your choice of 47 is wrong.  This value is also used for system mode,

No, it is not. System mode uses the other value, TARGET_PHYS_ADDR_SPACE_BITS, 
which this patch leaves untouched.

> and
> the kernel does use the negative half of the address space, so we need to
> have all 48 bits here.

I believe that TARGET_PHYS_ADDR_SPACE_BITS could be reduced to 56 bits. 
Anything less would presumably break handling of the address "sign" bit 55.

However, that would merely constitute an optimization, as there are no risk of 
generating architecturally invalid addresses at run-time in system mode.

-- 
Rémi Denis-Courmont
http://www.remlab.net/






reply via email to

[Prev in Thread] Current Thread [Next in Thread]