On Wed, Sep 25, 2019 at 9:16 AM Guo Ren <guo...@kernel.org> wrote: > > "Bits 63–54 are reserved for future use and must be > zeroed by software for forward compatibility." > > That doesn't mean 63-54 are belong to ppn, it's reserved for future > and nobody know 63-54 will be part of ppn. > Current riscv qemu ppn implementation is obviously wrong. It shouldn't > care the software's behavior, please follow the spec.
You have convinced me, I think this is an acceptable change. Alistair > > On Wed, Sep 25, 2019 at 11:58 PM Jonathan Behrens <finte...@gmail.com> wrote: > > > > > The specification is very clear: these bits are not part of ppn, not > > > part of the translation target address. The current code is against > > > the riscv-privilege specification. > > > > If all of the reserved bits are zero then the patch changes nothing. > > Further the only normative mention of the reserved bits in the spec > > says they must be: "Bits 63–54 are reserved for future use and must be > > zeroed by software for forward compatibility." Provided that software > > follows the spec current QEMU will behave properly. For software that > > ignores that directive an sets some of those bits, the spec says > > nothing about what hardware should do, so both the old an the new > > behavior are fine. > > > > Jonathan > > > > -- > Best Regards > Guo Ren > > ML: https://lore.kernel.org/linux-csky/
