On Mon, 13 Jul 2026 at 15:27, Philippe Mathieu-Daudé <[email protected]> wrote: > > On 4/3/26 19:35, Peter Xu wrote: > > On Thu, Feb 26, 2026 at 11:02:25PM +0100, Philippe Mathieu-Daudé wrote: > >> #define MR_SIZE(size) (int128_nz(size) ? (hwaddr)int128_get64( \ > >> int128_sub((size), int128_one())) : 0) > >> -#define MR_ADDR_WIDTH 16 > >> + > >> +static unsigned mr_addr_fmt_width(const MemoryRegion *mr) > >> +{ > >> + const unsigned int bits = 127 - clz128(mr->size); > >> + unsigned int width; > >> + > >> + if (bits <= 8) { > >> + width = 2; > >> + } else if (bits <= 16) { > >> + width = 4; > >> + } else if (bits <= 32) { > >> + width = 8; > >> + } else if (bits <= 64) { > >> + width = 16; > >> + } else { > >> + width = 20; > > > > Is there any case this can happen? I thought we don't have MR larger than > > 1<<64. Not a huge deal, though. > > > > Reviewed-by: Peter Xu <[email protected]> > > There are few uses of 0x1.0000.0000.0000.0000:
Yes; that's the largest possible MR size: exactly 2^64. Inside MemoryRegion we keep the size in an Int128; in some APIs (e.g. the ones for creating an MR, and the return value of memory_region_size()) we represent a size as a uint64_t, with UINT64_MAX being a special case meaning "actually 2^64". So here the largest possible value of 'bits' is 64: anything else would mean some bug elsewhere in QEMU resulting in an invalid mr->size somehow, I think. -- PMM
