On Fri, Jan 28, 2022 at 07:48:44AM +0100, Jan Beulich wrote: > On 26.01.2022 16:45, Roger Pau Monné wrote: > > On Wed, Jan 26, 2022 at 03:08:28PM +0100, Jan Beulich wrote: > >> On 26.01.2022 13:26, Roger Pau Monne wrote: > >>> --- a/xen/arch/x86/mm.c > >>> +++ b/xen/arch/x86/mm.c > >>> @@ -479,6 +479,26 @@ unsigned int page_get_ram_type(mfn_t mfn) > >>> return type ?: RAM_TYPE_UNKNOWN; > >>> } > >>> > >>> +bool is_iomem_range(uint64_t start, uint64_t size) > >> > >> Might be nice to have this sit next it is_iomem_page(). And wouldn't > >> at least "start" better be paddr_t? > > > > (paddr_t, size_t) would be better, but AFAICT size_t can be an > > unsigned long and on Arm32 that won't be suitable for holding a 64bit > > BAR size. > > Talking of representing the range - a BAR occupying one part of a > page overlapping an E820 entry covering another part of that same > page is going to be equally bad, I think. The range may therefore > want expressing in page granularity. This may then be easier as > [start,end], at least on the calling side (can use PFN_DOWN() > twice then).
Yes, indeed, would likely be better. Then I can make both parameters unsigned long. I also think is_memory_hole would be a suitable name given the new implementation? Thanks, Roger.
