Re: [PULL 04/11] xen-mapcache: Remove 32bit support

[Peter Xu <peterx@xxxxxxxxxx>]

On Fri, Sep 18, 2026 at 02:14:26PM +0100, Ross Lagerwall wrote:
> On 9/18/26 12:39 PM, Peter Xu wrote:
> > QEMU has switched to 64bit-only hosts for all system emulations.
> > 
> > Reviewed-by: Richard Henderson <richard.henderson@xxxxxxxxxx>
> > Link: https://lore.kernel.org/r/20260818172012.3052821-5-peterx@xxxxxxxxxx
> > Cc: Stefano Stabellini <sstabellini@xxxxxxxxxx>
> > Cc: Anthony PERARD <anthony@xxxxxxxxxxxxxx>
> > Cc: "Edgar E. Iglesias" <edgar.iglesias@xxxxxxxxx>
> > Cc: xen-devel@xxxxxxxxxxxxxxxxxxxx
> > Signed-off-by: Peter Xu <peterx@xxxxxxxxxx>
> > ---
> >   hw/xen/xen-mapcache.c | 12 ++----------
> >   1 file changed, 2 insertions(+), 10 deletions(-)
> > 
> > diff --git a/hw/xen/xen-mapcache.c b/hw/xen/xen-mapcache.c
> > index 85cf0cf359..e30c07c2ee 100644
> > --- a/hw/xen/xen-mapcache.c
> > +++ b/hw/xen/xen-mapcache.c
> > @@ -26,11 +26,7 @@
> >   #include <xenevtchn.h>
> >   #include <xengnttab.h>
> > -#if HOST_LONG_BITS == 32
> > -#  define MCACHE_MAX_SIZE     (1UL<<31) /* 2GB Cap */
> > -#else
> > -#  define MCACHE_MAX_SIZE     (1UL<<35) /* 32GB Cap */
> > -#endif
> > +#define MCACHE_MAX_SIZE     (1UL << 35) /* 32GB Cap */
> >   /* This is the size of the virtual address space reserve to QEMU that 
> > will not
> >    * be use by MapCache.
> > @@ -151,11 +147,7 @@ void xen_map_cache_init(phys_offset_to_gaddr_t f, void 
> > *opaque)
> >           exit(EXIT_FAILURE);
> >       }
> > -    if (HOST_LONG_BITS == 32) {
> > -        bucket_shift = 16;
> > -    } else {
> > -        bucket_shift = 20;
> > -    }
> > +    bucket_shift = 20;
> >       if (geteuid() == 0) {
> >           rlimit_as.rlim_cur = RLIM_INFINITY;
> 
> Using a local variable here to store a constant is a bit weird and its only 
> use
> is to be stored as MapCache.bucket_shift and MapCache.bucket_size which are
> effectively constant. Not sure why this isn't just a couple of #defines at the
> top and used everywhere bucket_shift and bucket_size is needed. Perhaps that 
> is
> further cleanup to be done separately...

True..

It's my bad not noticing that relevant people were not properly copied when
sending the patches; I thought each patch will have its own set of CC from
get_maintainers.pl, but it didn't actually work and I didn't notice.  I
only notice it when I was just to send a pull, hence added Cc: explicitly
at least in the pull sent, feeling that these changes are mostly cosmotic
and safe.

It'll be great if this can be done separately, makes me easier.  If there's
any strong feeling on any of the changes, please speak and then I'll redo
the work.

Thanks,

-- 
Peter Xu