Re: [PATCH 3/7] mshv: Rename mshv_mem_region to mshv_region

[Stanislav Kinsburskii]

On Fri, Apr 03, 2026 at 03:54:52AM +0000, Anirudh Rayabharam wrote:
> On Thu, Apr 02, 2026 at 10:57:09AM -0700, Stanislav Kinsburskii wrote:
> > On Thu, Apr 02, 2026 at 04:33:24PM +0000, Anirudh Rayabharam wrote:
> > > On Wed, Apr 01, 2026 at 10:12:40PM +0000, Stanislav Kinsburskii wrote:
> > > > The mshv_mem_region structure represents guest address space regions,
> > > > which can be either RAM-backed memory or memory-mapped IO regions
> > > > without physical backing. The "mem_" prefix incorrectly suggests the
> > > > structure only handles memory regions, creating confusion about its
> > > > actual purpose.
> > > > 
> > > > Remove the "mem_" prefix to align with existing function naming
> > > > (mshv_region_map, mshv_region_pin, etc.) and accurately reflect that
> > > > this structure manages arbitrary guest address space mappings
> > > > regardless of their backing type.
> > > 
> > > I don't think the "mem_" prefix automatically suggested the backing
> > > type.
> > > 
> > 
> > What else can it suggest?
> 
> To me it just suggested that the struct contained info or properties of
> a guest memory region. The name itself didn't suggest what backing type
> the memory has.
> 

Right, that’s what the old name suggested to me too. And that’s the
problem. It’s inaccurate for MMIO regions. They have nothing to do with
memory. They are never backed by it.

> > 
> > > Isn't mshv_region too vague now? Region of what?
> > > 
> > 
> > The region of address space, which can or can not be backed by memory.
> 
> Yeah but that's not obvious just from the new name. The new name just
> says mshv_region and doesn't what the region is of.
> 

I hear you, but what else can we do? Keeping mshv_mem_region isn’t good
for the reasons above. Renaming it to `mshv_gpa_region` also feels
redundant detailization.

To me, this is a good tradeoff. Yes, it’s a bit too generic. But it’s
concise, and we don’t have any other regions in the codebase. So I don’t
think it will cause confusion.

Thanks,
Stanislav

> Thanks,
> Anirudh.
> 
> > 
> > Thanks,
> > Stanislav
> > 
> > > Thanks,
> > > Anirudh.