target/arm: Fix handling of LPAE block descriptors
commit39a1fd25287f5dece59fdf4752491faf59310296
authorPeter Maydell <peter.maydell@linaro.org>
Fri, 4 Mar 2022 16:56:28 +0000 (4 16:56 +0000)
committerPeter Maydell <peter.maydell@linaro.org>
Fri, 18 Mar 2022 10:55:15 +0000 (18 10:55 +0000)
tree9fec639d4f2ac28f23d9cb55691d44be31ef10b4
parentc179d3be7bd03edb717c4b953faa285513b6301f
target/arm: Fix handling of LPAE block descriptors

LPAE descriptors come in three forms:

 * table descriptors, giving the address of the next level page table
 * page descriptors, which occur only at level 3 and describe the
   mapping of one page (which might be 4K, 16K or 64K)
 * block descriptors, which occur at higher page table levels, and
   describe the mapping of huge pages

QEMU's page-table-walk code treats block and page entries
identically, simply ORing in a number of bits from the input virtual
address that depends on the level of the page table that we stopped
at; we depend on the previous masking of descaddr with descaddrmask
to have already cleared out the low bits of the descriptor word.

This is not quite right: the address field in a block descriptor is
smaller, and so there are bits which are valid address bits in a page
descriptor or a table descriptor but which are not supposed to be
part of the address in a block descriptor, and descaddrmask does not
clear them.  We previously mostly got away with this because those
descriptor bits are RES0; however with FEAT_BBM (part of Armv8.4)
block descriptor bit 16 is defined to be the nT bit.  No emulated
QEMU CPU has FEAT_BBM yet, but if the host CPU has it then we might
see it when using KVM or hvf.

Explicitly zero out all the descaddr bits we're about to OR vaddr
bits into.

Resolves: https://gitlab.com/qemu-project/qemu/-/issues/790
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Message-id: 20220304165628.2345765-1-peter.maydell@linaro.org
target/arm/helper.c