Re: of AVR target page size

[Michael Rolnik]

I guess we can add some bits TARGET_PAGE_BITS, this will make us to push some portion of SRAM into the CPU.

Michael Rolnik

On Thu, Mar 18, 2021 at 12:33 AM Peter Maydell <peter.maydell@linaro.org> wrote:

On Wed, 17 Mar 2021 at 20:17, Dr. David Alan Gilbert
<dgilbert@redhat.com> wrote:
>
> Hi Michael,
>   I noticed your AVR code defines:
>
>   #define TARGET_PAGE_BITS 8
>
> and has an explanation of why.
>
> Note however that's not going to work with the current live
> migration/snapshotting code, since you're a couple of bits smaller
> than the smallest page size we had so far, and for many years
> the RAM migration code has stolen the bottom few bits of the address
> as a flag field, and has already used 0x100 up; see migration/ram.c
> RAM_SAVE_FLAG_*    - and it's actually tricky to change it, because if
> you change it then it'll break migration compatibility with existing
> qemu's.

If you want to use low bits as flags for other stuff, you
should have a compile time assert that you have the number
of bits you expect, or otherwise force a compile error.
Otherwise you'll end up with unpleasant surprises like this one...

I think that for the cpu-all.h uses of low bits we would
end up with a compile error for excessively small TARGET_PAGE_BITS
because we define the bits like this:
#define TLB_DISCARD_WRITE   (1 << (TARGET_PAGE_BITS_MIN - 6))
and I expect the compiler will complain if the RHS of the '<<'
is a negative constant. But I don't know if that's deliberate
or a happy accident :-)

thanks
-- PMM

--

Best Regards,
Michael Rolnik