On Sat, Oct 12, 2019 at 10:33 AM Palmer Dabbelt wrote:
>
> On Wed, 25 Sep 2019 17:14:21 PDT (-0700), guo...@kernel.org wrote:
> > From: Guo Ren
> >
> > Highest 10 bits of PTE are reserved in riscv-privileged, ref: [1], so we
> > need to ignore them. They cannot be a part of ppn.
> >
> > 1: The RI
There is nowhere in the spec that ever says what hardware has to do if
any of those reserved bits are non-zero. Hardware is certainly not
required to ignore them and treat the PTE as being valid (which is
what this patch does). I'd argue that since only buggy code would ever
set these bits, QEMU sh
The patch didn't wrap the physical address space directly, just follow the spec.
I admit that I am trying to use the compliance specification to allow
qemu to support some non-standard software.
But compliance specification and wrapping the physical address space
are different things.
I'm preparing
On Wed, 25 Sep 2019 17:14:21 PDT (-0700), guo...@kernel.org wrote:
From: Guo Ren
Highest 10 bits of PTE are reserved in riscv-privileged, ref: [1], so we
need to ignore them. They cannot be a part of ppn.
1: The RISC-V Instruction Set Manual, Volume II: Privileged Architecture
4.4 Sv39: Pag
From: Guo Ren
Highest 10 bits of PTE are reserved in riscv-privileged, ref: [1], so we
need to ignore them. They cannot be a part of ppn.
1: The RISC-V Instruction Set Manual, Volume II: Privileged Architecture
4.4 Sv39: Page-Based 39-bit Virtual-Memory System
4.5 Sv48: Page-Based 48-bit V
